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Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the procedures used by the protocols for mobility management and session management 
between User Equipment (UE) and Mobility Management Entity (MME) in the Evolved Packet System (EPS). These 
protocols belong to the non-access stratum (NAS). 

The EPS Mobility Management (EMM) protocol defined in the present document provides procedures for the control of 
mobility when the User Equipment (UE) is using the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN). 
The EMM protocol also provides control of security for the NAS protocols. 

The EPS Session Management (ESM) protocol defined in the present document provides procedures for the handling of 
EPS bearer contexts. Together with the bearer control provided by the access stratum, this protocol is used for the 
control of user plane bearers. 

For both NAS protocols the present document specifies procedures for the support of inter-system mobihty between 
E-UTRAN and other 3GPP or non-3GPP access networks: 

For inter-system mobility between E-UTRAN and GERAN or UTRAN, this includes rules for a mapping 
between parameters and procedures used by the NAS protocols defined in the present document and the NAS 
protocols specified in 3GPP TS 24.008 [13]. 

For inter-system mobility between E-UTRAN and generic non-3GPP access networks, this includes specific 
NAS procedures to maintain IP connectivity to the PDN Gateway and to provide parameters needed by the UE 
when using mobility management based on Dual-Stack Mobile IPv6 (see 3GPP TS 24.303 [14]) or MIPv4 
(see 3GPPTS 24.304 [15]). 

The present document is appUcable to the UE and to the MobiUty Management Entity (MME) in the EPS. 
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3 



Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPP TR 21.905 [1]. 

Ix CS fallback capable UE: A UE that uses a CS infrastructure for a voice call and other CS-domain services by 
falUng back to cdma2000® Ix access network if the UE is served by E-UTRAN when a CS service is requested. 

Aggregate maximum bit rate: The maximum bit rate that limits the aggregate bit rate of a set of non-GBR bearers of a 
UE. Definition derived fi-om 3GPP TS 23.401 [10]. 

Allowed CSG list: A list of CSG IDs stored in the UE. A UE is able to access only those CSG cells that have a CSG ID 
in this hst. 

CS fallback capable UE: A UE that uses a CS infrastructure for a voice call and other CS-domain services by falling 
back to A/Gb or lu mode if the UE is served by E-UTRAN when a CS service is requested. 

CSG ID: A CSG ID is an identifier defined in 3GPP TS 23.003 [2] and associated to a cell or group of cells to which 
access is restricted to a defined group of users. 

CSG selection: A UE supporting CSG selection selects CSG cell either automatically based on the list of allowed CSG 
identities or manually based on user selection of CSG on indication of hst of available CSGs. Definition derived from 
3GPPTS 23.122 [6] 

EMM context: An EMM context is estabhshed in the UE and the MME when an attach procedure is successfully 
completed. 

EMM-CONNECTED mode: A UE is in EMM-CONNECTED mode when a NAS signalling connection between UE 
and network is estabhshed. The term EMM-CONNECTED mode used in the present document corresponds to the term 
ECM-CONNECTED state used in 3GPP TS 23.401 [10]. 

EMM-IDLE mode: A UE is in EMM-IDLE mode when no NAS signalling cormection between UE and network 
exists. The term EMM-IDLE mode used in the present dociunent corresponds to the term ECM-IDLE state used in 
3GPPTS 23.401 [10]. 

EPS services: Within the context of this specification, EPS services is used as a synonym for GPRS services in 
3GPPTS 24.008 [13]. 

Evolved packet core network: the successor to the 3GPP Release 7 packet- switched core network, developed by 3GPP 
within the framework of the 3GPP System Architecture Evolution (SAE). 

Evolved packet system: The evolved packet system (EPS) or evolved 3GPP packet-switched domain consists of the 
evolved packet core network and the evolved universal terrestrial radio access network. Definition derived from 
3GPPTS 23.401 [10]. 

Dedicated bearer: An EPS bearer that is associated with uplink packet filters in the UE and downlink packet filters in 
the PDN GW where the filters only match certain packets. Definition derived from 3GPP TS 23.401 [10]. 

Default bearer: An EPS bearer that is associated with "match all" uphnk and downlink packet filters in the UE and the 
PDN GW, respectively. Definition derived from 3GPP TS 23.401 [10]. 

GBR bearer: An EPS bearer that uses dedicated network resources related to a guaranteed bit rate (GBR) value, which 
are permanently allocated at EPS bearer establishment/modification. Definition derived from 3GPP TS 23.401 [10]. 
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Initial NAS message: A NAS message is considered as an initial NAS message, if this NAS message can trigger the 
estabhshment of a NAS signalhng connection. For instance, the ATTACH REQUEST message is an initial NAS 
message. 

IPv4v6 capability: capability of the IP stack associated with a UE to support a dual stack configuration with both an 
IPv4 address and an IPv6 address allocated. 

KUobit: 1000 bits. 

Last Visited Registered TAI: A TAI which is contained in the TAI list that the UE registered to the network and 
which identifies the tracking area last visited by the UE. 

Linlied Bearer Identity: This identity indicates to which default bearer the additional bearer resource is linked. 

Mapped EPS security context: a mapped security context to be used in EPS. Definition derived from 
3GPPTS 33.401 [19]. 

Megabit: 1,000,000 bits. 

Message header: a standard L3 message header as defined in 3GPP TS 24.007 [12]. 
MME area: An area containing tracking areas served by an MME. 

NAS signalling connection recovery: is a mechanism initiated by the NAS to restore the NAS signalling connection on 
indication of "RRC connection failure" by the lower layers. 

NAS signalling connection: is a peer to peer S 1 mode connection between UE and MME. A NAS signalling 
connection consists of the concatenation of an RRC connection via the "LTE-Uu" interface and an SlAP connection via 
the SI interface. Additionally, for the purpose of optimized handover or idle mode mobility from cdma2000® HRPD 
access to E-UTRAN (see 3GPP TS 23.402 [11]), the NAS signalling connection can consist of a concatenation of an 
SlOl-AP connection and a signalling tunnel over a cdma2000® HRPD access network. 

NOTE: cdma2000® is a registered tradenaark of the Telecommunications Industry Association (TIA-USA). 

Non-access stratum protocols: The protocols between UE and MSC or SGSN that are not terminated in the UTRAN, 
and the protocols between UE and MME that are not terminated in the E-UTRAN. Definition derived from 
3GPPTS 21.905 [1]. 

Non-EPS services: services provided by CS domain. Within the context of this specification, non-EPS services is used 
as a synonym for non-GPRS services in 3GPP TS 24.008 [13]. A UE which camps on E-UTRAN can attach to both 

EPS services and non-EPS services. 

Non-GBR bearer: An EPS bearer that uses network resources that are not related to a guaranteed bit rate (GBR) value. 
Definition derived from 3GPP TS 23.401 [10]. 

PDN address: an IP address assigned to the UE by the Packet Data Network Gateway (PDN GW). 

Plain NAS message: a NAS message with a header including neither a message authentication code nor a sequence 
number. 

Procedure Transaction Identity: An identity which is dynamically allocated by the UE for the UE requested ESM 
procedures. The procedure transaction identity is released when the procedure is completed. 

RAT-related TMSI: When the UE is camping on an E-UTRAN cell, the RAT-related TMSI is the GUTI; when it is 
camping on a GERAN or UTRAN cell, the RAT-related TMSI is the P-TMSI. 

Registered PLMN: The PLMN on which the UE is registered. The identity of the registered PLMN is provided to the 
UE within the GUTI. 

The label (SI mode only) indicates that this subclause or paragraph applies only to a system which operates in S 1 
mode, i.e. with a functional division that is in accordance with the use of an SI interface between the radio access 
network and the core network. In a multi-access system this case is determined by the current serving radio access 
network. 

SlOl mode: applies to a system that operates with a functional division that is in accordance with the use of an SlOl 
interface. For the definition of the SlOl reference point, see 3GPP TS 23.402 [1 1]. 
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TAI list: A list of TAIs that identify the tracking areas that the UE can enter without performing a tracking area 
updating procedure. The TAIs in a TAI list assigned by an MME to a UE pertain to the same MME area. Additionally, 
the TAIs in a TAI list assigned by an MME to a CS fallback capable UE pertain to the same location area. In this case, 
the defining of the relationship between the tracking area(s) and the location area(s) is operator specific. 

Traffic flow aggregate: A temporary aggregate of packet filters that are included in a UE requested bearer resource 
allocation procedure or a UE requested bearer resource modification procedure and that is inserted into a traffic fiow 
template (TFT) for an EPS bearer context by the network once the UE requested bearer resource allocation procedure or 
UE requested bearer resource modification procedure is completed. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.401 [10] apply: 
MME pool area 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.008 [13] apply: 

A/Gb mode 
lu mode 
TFT 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 33.102 [18] apply: 
UMTS security context 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 33.401 [19] apply: 

Current EPS security context 
EPS security context 

Kasme 
K'asme 

Mapped security context 
Native EPS security context 
Non-current EPS security context 



3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPP TR 21.905 [1]. 



AKA 


Authentication and Key Agreement 


AMBR 


Aggregate Maximum Bit Rate 


APN 


Access Point Name 


APN-AMBR 


APN Aggregate Maximum Bit Rate 


ARP 


Allocation Retention Priority 


CGI 


Cell Global Identifier 


CSG 


Closed Subscriber Group 


E-UTRA 


Evolved Universal Terrestrial Radio Access 


E-UTRAN 


Evolved Universal Terrestrial Radio Access Network 


ECM 


EPS Connection Management 


eKSI 


Key Set Identifier for E-UTRAN 


EMM 


EPS MobiUty Management 


EPC 


Evolved Packet Core Network 


EPS 


Evolved Packet System 


ESM 


EPS Session Management 


GBR 


Guaranteed Bit Rate 


GUMMEI 


Globally Unique MME Identifier 


GUTI 


Globally Unique Temporary Identifier 


HRPD 


High Rate Packet Data 


ISR 


Idle mode Signalling Reduction 


kbps 


Kilobits per second 


KSI 


Key Set Identifier 


M-TMSI 


M-Temporary Mobile Subscriber Identity 
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Mbps 
MBR 
MME 



Megabits per second 
Maximum Bit Rate 
Mobility Management Entity 
MME Code 

Protocol Configuration Options 

Protocol Discriminator 

Packet Data Network Gateway 

Procedure Transaction Identity 

QoS Class Identifier 

Quality of Service 

Radio Resource Control 

S-Temporary Mobile Subscriber Identity 

SlOl Application Protocol 

SI Application Protocol 

System Architecture Evolution 

Tracking Area Code 

Tracking Area Identity 

Traffic Flow Template 

Transaction Identifier 

Temporary Identity used in Next update 



MMEC 



PCO 
PD 



PDNGW 



PTI 
QCI 
QoS 
RRC 



S-TMSI 
SlOl-AP 



SlAP 

SAE 

TAC 

TAI 

TFT 

TI 

TIN 



4 



General 



4.1 Overview 

The non-access stratum (NAS) described in the present document forms the highest stratum of the control plane 
between UE and MME at the radio interface (reference point "LTE-Uu"; see 3GPP TS 23.401 [10]). 

Main functions of the protocols that are part of the NAS are: 

- the support of mobility of the user equipment (UE); and 

- the support of session management procedures to establish and maintain IP connectivity between the UE and a 
packet data network gateway (PDN GW). 

NAS security is an additional function of the NAS providing services to the NAS protocols, e.g. integrity protection and 
ciphering of NAS signalling messages. 

For the support of the above functions, the following procedures are supplied within this specification: 

- elementary procedures for EPS mobiUty management in clause 5; and 

- elementary procedures for EPS session management in clause 6. 

Complete NAS transactions consist of specific sequences of elementary procedures. Examples of such specific 
sequences can be found in 3GPP TS 23.401 [10]. 

The NAS for EPS follows the protocol architecture model for layer 3 as described in 3GPP TS 24.007 [12]; however, 
due to the objective of EPS to provide the subscriber with a "ready-to-use" IP connectivity and an "always-on" 
experience, there is a linkage between mobiUty management and session management procedures during the attach 
procedure (see subclause 4.2). 

Signalling procedures for the control of NAS security are described as part of the EPS mobility management in 
clause 5. In addition to that, principles for the handing of EPS security contexts and for the activation of ciphering and 
integrity protection, when a NAS signalling connection is established, are provided in subclause 4.4. 
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4.2 Linkage between the protocols for EPS mobility 
management and EPS session management 

During the EPS attach procedure, the network activates a default EPS bearer context. Additionally, the network can 
activate one or several dedicated EPS bearer contexts in parallel. To this purpose the EPS session management 
messages for the default EPS bearer context activation are transmitted in an information element in the EPS mobility 
management messages. The UE and the network execute the attach procedure, the default EPS bearer context activation 
procedure, and the dedicated EPS bearer context activation procedure in parallel. The UE and network shall complete 
the combined default EPS bearer context activation procedure and the attach procedure before the dedicated EPS bearer 
context activation procedure is completed. The success of the attach procedure is dependent on the success of the 
default EPS bearer context activation procedure. If the attach procedure fails, then the ESM session management 
procedures also fail. 

Except for the attach procedure, during EMM procedures the transmission of ESM messages shall be suspended. 

4.3 UE mode of operation 

A UE attached for EPS services may operate in one of the following operation modes: 

- PS mode of operation: the UE registers only to EPS services; 

- CS/PS mode 1 of operation: the UE is CS fallback capable and configured to use CS fallback, and non-EPS 
services are preferred. The UE registers to both EPS and non-EPS services; and 

CS/PS mode 2 of operation: the UE is CS fallback capable and configured to use CS fallback, and EPS services 
are preferred. The UE registers to both EPS and non-EPS services. 

4.4 NAS security 

4.4.1 General 

This clause describes the principles for the handling of EPS security contexts in the UE and in the MME and the 
procedures used for the security protection of EPS NAS messages between UE and MME. Security protection involves 
integrity protection and ciphering of the EMM and ESM NAS messages. 

The signalhng procedures for the control of NAS security are part of the EMM protocol and are described in detail in 

clause 5. 

NOTE: The use of ciphering in a network is an operator option. In this subclause, for the ease of description, it is 
assumed that ciphering is used, unless explicitly indicated otherwise. Operation of a network without 
ciphering is achieved by configuring the MME so that it always selects the "nuU ciphering algorithm", 
EEAO. 

4.4.2 Handling of EPS security contexts 
4.4.2.1 General 

The security parameters for authentication, integrity protection and ciphering are tied together in an EPS security 
context and identified by a key set identifier for E-UTRAN (eKSI). The relationship between the security parameters is 
defined in 3GPP TS 33.401 [19]. 

Before security can be activated, the MME and the UE need to establish an EPS security context. Usually, the EPS 
security context is created as the result of an authentication procedure between MME and UE. Alternatively, during 
inter-system handover from A/Gb mode to SI mode or lu mode to SI mode, the MME and the UE derive a mapped 
EPS security context from a UMTS security context that has been estabhshed while the UE was in A/Gb mode or lu 
mode. 

The key set identifier eKSI is assigned by the MME either during the authentication procedure or, for the mapped 
security context, during the handover procedure. The eKSI consists of a value and a type of security context parameter 
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indicating whether an EPS security context is a native EPS security context or a mapped EPS security context. When 
the EPS security context is a native EPS security context, the eKSI has the value of KSIasmej and when the current EPS 
security context is a mapped EPS security context, the eKSI has the value of KSIsgsn- 

The eKSI can be used to establish the secure exchange of NAS messages at the next establishment of a NAS signalling 
connection without executing a new authentication procedure (see subclause 4. 4. 2. 3). To this purpose the initial NAS 
messages (ATTACH REQUEST, TRACKING AREA UPDATE REQUEST, DETACH REQUEST, SERVICE 
REQUEST and EXTENDED SERVICE REQUEST) and the SECURITY MODE COMMAND message contain an 
eKSI in the NAS key set identifier IE or the value part of eKSI in the KSI and sequence number IE indicating the 
current EPS security context used to integrity protect the message. 

In the present document, when the UE is required to delete an eKSI, the UE shall set the eKSI to the value "no key is 
available" and consider also the associated keys Kasme or K'asme . EPS NAS ciphering key and EPS NAS integrity key 
invaUd (i.e. the EPS NAS security context associated with the eKSI as no longer vaUd). 

NOTE: In some specifications the term ciphering key sequence number might be used instead of the term Key Set 
Identifier (KSI). 

The EPS security context is taken into use, when the MME initiates a security mode control procedure or, if it is a 
mapped EPS security context, during the inter-system handover procedure. The security context which has been taken 
into use by the network most recently is called current security context. 

The UE and the MME need to be able to maintain two EPS security contexts simultaneously, since: 

- after a re-authentication, the UE and the MME can have both a current EPS security context and a new EPS 
security context which has not yet been taken into use; and 

after an inter-system handover from A/Gb mode to S 1 mode or lu mode to SI mode, the UE and the MME can 
have both a mapped EPS security context which is the current EPS security context and a native EPS security 
context that was created during a previous access in SI mode or SlOl mode. 

The number of EPS security contexts that need to be maintained simultaneously by the UE and the MME is limited by 
the following requirements: 

- After a successful (re-)authentication, the MME and the UE shall delete any old EPS security context different 
from the current EPS security context. 

- When a new EPS security context is taken into use through a security mode control procedure, the MME and the 
UE shall delete the previously current EPS security context. 

When a new EPS security context is taken into use during the inter-system handover from A/Gb mode to S 1 
mode or lu mode to SI mode, the MME and the UE shall not delete the previously current native EPS security 
context. 

- When the MME and the UE derive a new mapped EPS security context during inter-system handover from A/Gb 
mode to SI mode or lu mode to SI mode, the MME and the UE shall delete any existing mapped EPS security 
context. 

- When a native EPS security context is taken into use, the MME and the UE shall delete any mapped EPS 
security context. 

When the UE moves from EMM-CONNECTED to EMM-IDLE, it shall keep the current EPS security context. 

4.4.2.2 Establishment of a mapped EPS security context during intersystem 
liandover 

In order for the UE to derive a mapped EPS security context for an inter-system change from A/Gb mode or lu mode to 
SI mode in EMM-CONNECTED mode, the MME shall generate a KSIsgsn. create a nonceMME and generate the K'asme 
using the created nonceMME as indicated in 3GPP TS 33.401 [19]. The MME shall include the selected NAS algorithms, 
nonccMME and generated KSIsgsn (associated with the K'asme) in the NAS security transparent container for handover to 
E-UTRAN. The MME shall derive the EPS NAS keys from K'asme and the MME shall set the uphnk and downlink 
NAS COUNT counters of the mapped EPS security context to zero. 
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4.4.2.3 



Establishment of secure exchange of NAS messages 



Secure exchange of NAS messages via a NAS signalling connection is usually established by the MME during the 
attach procedure by initiating a security mode control procedure. After successful completion of the security mode 
control procedure, except for the messages specified in subclauses 4.4.4 and 4.4.5, all NAS messages exchanged 
between the UE and the MME are sent integrity protected and ciphered using the current EPS security algorithm. 

During inter-system handover from A/Gb mode to SI mode or lu mode to SI mode, secure exchange of NAS messages 
is established between the MME and the UE by: 

the transmission of NAS security related parameters encapsulated in the AS signalling from the MME to the UE 
triggering the inter-system handover (see 3GPP TS 33.401 [19]). The UE uses these parameters to generate the 
mapped EPS security context; and, 

- after the handover, the transmission of a TRACKING AREA UPDATE REQUEST message from the UE to the 
MME. The UE shall send this message integrity protected using the mapped EPS security context, but 
unciphered. From this time onward, except for the messages specified in subclauses 4.4.4 and 4.4.5, all NAS 
messages exchanged between the UE and the MME are sent integrity protected and ciphered using the mapped 
EPS security context. 

The secure exchange of NAS messages shall be continued after SI mode to SI mode handover. It is terminated after 
inter-system handover from SI mode to A/Gb mode or lu mode or when the NAS signalling connection is released. 

When a UE in EMM-IDLE mode establishes a new NAS signalling connection and has a vaUd current EPS security 
context, secure exchange of NAS messages can be re-established in the following ways: 

1) Except for the case described in item 3 below, the UE shall transmit the initial NAS message integrity protected 
with the current EPS security context, but unciphered. The UE shall include the eKSI indicating the current EPS 
security context value in the initial NAS message. The MME shall check whether the eKSI included in the initial 
NAS message belongs to an EPS security context available in the MME, and shall verify the MAC of the NAS 
message. If the verification is successful, the MME may re-establish the secure exchange of NAS messages: 

- by replying with a NAS message that is integrity protected and ciphered using the current EPS security 
context. From this time onward, except for the messages specified in subclauses 4.4.4 and 4.4.5, all NAS 
messages exchanged between the UE and the MME are sent integrity protected and ciphered; or 

- by initiating a security mode control procedure. This can be used by the MME to take a cached or a new EPS 
security context into use or to modify the current EPS security context by selecting new NAS security 
algorithms; or 

2) If the initial NAS message was a SERVICE REQUEST message or EXTENDED SERVICE REQUEST 
message, secure exchange of NAS messages is triggered by the indication from the lower layers that the user 
plane radio bearers are successfully set up. After successful completion of the procedure, except for the 
messages specified in subclauses 4.4.4 and 4.4.5, all NAS messages exchanged between the UE and the MME 
are sent integrity protected and ciphered. 

3) If the UE has no current EPS security context and performs a tracking area updating procedure after an inter- 
system change in idle mode from A/Gb mode to S 1 mode or lu mode to S 1 mode, the UE shall send the 
TRACKING AREA UPDATE REQUEST message without integrity protection and encryption. The UE shall 
include a nonce and a GPRS ciphering key sequence number for creation of a mapped security context. The 
MME creates a fresh mapped EPS security context and takes this context into use by initiating a security mode 
control procedure. This re-establishes the secure exchange of NAS messages. 



When the MME initiates a re-authentication to create a new EPS security context, the messages exchanged during the 
authentication procedure are integrity protected and ciphered using the current EPS security context, if any. 

Both UE and MME shall continue to use the current EPS security context, until the MME initiates a security mode 
control procedure. The SECURITY MODE COMMAND message sent by the MME includes the eKSI of the new EPS 
security context to be used. The MME shall send the message integrity protected with the new EPS security context, but 
unciphered. When the UE responds with a SECURITY MODE COMPLETE, it shall send the message integrity 
protected and ciphered with the new EPS security context. 



4.4.2.4 



Change of security l<eys 
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The MME can also modify the current EPS security context or take an existing native EPS security context into use, by 
sending a SECURITY MODE COMMAND message including the eKSI of the EPS security context to be modified and 
including a new set of selected NAS security algorithms. In this case the MME shall send the SECURITY MODE 
COMMAND message integrity protected with the modified EPS security context, but unciphered. When the UE replies 
with a SECURITY MODE COMPLETE message, it shall send the message integrity protected and ciphered with the 
modified EPS security context. 

4.4.3 Handling of NAS COUNT and NAS sequence number 

4.4.3.1 General 

There are two separate counters NAS COUNT for each EPS security context: one related to uplink NAS messages and 
one related to downlink NAS messages. The NAS COUNT counters use 24 bit internal representation and are 
independently maintained by UE and MME. The NAS COUNT is constructed as a NAS sequence number (least 
significant bits) concatenated with a NAS overflow counter (most significant bits). 

When NAS COUNT is input to NAS ciphering or NAS integrity algorithms it is considered to be a 32-bit entity where 
the most significant bits are padded with zeros. 

During the handover from UTRAN/GERAN to E-UTRAN, if the mapped EPS security context is taken into use, the 
NAS COUNT values for this EPS security context shall be initiaUzed to zero in the UE and the network for upUnk and 

downlink NAS messages. 

The NAS sequence number part of the NAS COUNT is exchanged between the UE and the MME as part of the NAS 
signalling. After each new or retransmitted outbound security protected NAS message, the sender shall always increase 
the NAS COUNT number by one. Specifically, the NAS sequence number is increased by one, and if the result is zero 
(due to wrap around), the NAS overflow counter is also incremented by one (see subclause 4.4.3.5). The receiving side 
estimates the NAS COUNT used by the sending side. Specifically, if the NAS sequence number wraps around, the NAS 
overflow counter is incremented by one. 

4.4.3.2 Replay protection 

Replay protection shall be supported for received NAS messages both in the MME and the UE. However, since the 
realization of replay protection does not affect the interoperability between nodes, no specific mechanism is required for 
implementation. 

Replay protection must assure that one and the same NAS message is not accepted twice by the receiver. Specifically, 
for a given NAS security context, a given NAS COUNT value shall be accepted at most one time and only if message 
integrity verifies correctly. 

4.4.3.3 Integrity protection and verification 

The sender shall use its locally stored NAS COUNT as input to the integrity protection algorithm. 

The receiver shall use the NAS sequence number included in the received message and an estimate for the NAS 
overflow counter to form the NAS COUNT input to the integrity verification algorithm. 

The algorithm to calculate the integrity protection information is specified in 3GPP TS 33.401 [19], and the integrity 
protection shall include octet 6 to n of the security protected NAS message, i.e. the sequence number IE and the NAS 
message IE. In addition to the data that is to be integrity protected, the constant BEARER ID, DIRECTION bit and 
COUNT are input to the integrity protection algorithm. These parameters are described in 3GPP TS 33.401 [19]. 

4.4.3.4 Ciphering and deciphering 

The sender shall use its locally stored NAS COUNT as input to the ciphering algorithm. 

The receiver shall use the NAS sequence number included in the received message and an estimate for the NAS 
overflow counter to form the NAS COUNT input to the deciphering algorithm. 

The input parameters for the NAS ciphering algorithms shall be the same as the ones used for NAS integrity protection 
as described in subclause 4.4.3.3, with the addition that the length of the key stream to be generated by the encryption 
algorithms. 
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4.4.3.5 NAS COUNT wrap around 

If, when increasing the NAS COUNT as specified above, the MME detects that its NAS COUNT is "close" to wrap 
aroimd, (close to 2^*), the MME shall initiate a new AKA procedure with the UE, leading to a new estabUshed NAS 
security context and the NAS COUNT being reset to in both the UE and the MME when the new NAS security 
context is activated as discussed above. 

Similarly, the MME shall initiate an AKA procedure if it detects that the UE's uplink NAS COUNT is close to wrap 
around. If for some reason a new Kasme has not been established using AKA before the NAS COUNT wraps around, 
the node (MME or UE) in need of sending a NAS message shall instead release the NAS signalling connection. Prior to 
sending the next uplink NAS message, the UE shall delete the eKSI indicating the current EPS security context. 

4.4.4 Integrity protection of NAS signalling messages 

4.4.4.1 General 

For the UE, integrity protected signalling is mandatory for the NAS messages once a valid EPS secmty context exists 
and has been taken into use. For the network, integrity protected signalling is mandatory for the NAS messages once a 
secure exchange of NAS messages has been established for the NAS signalling connection. Integrity protection of all 
NAS signalling messages is the responsibility of the NAS. It is the network which activates integrity protection. 

Details of the integrity protection and verification of NAS signalling messages are specified in 3GPP TS 33.401 [19]. 

When both ciphering and integrity protection are activated, the NAS message is first encrypted and then the encrypted 
NAS message and the NAS sequence number are integrity protected by calculating the MAC. 

When only integrity protection is activated, and ciphering is not activated, the unciphered NAS message and the NAS 
sequence number are integrity protected by calculating the MAC. 

When during the EPS attach procedure an ESM message is piggybacked in an EMM message, there is only one 
sequence number IE and one message authentication code IE, if any, for the combined NAS message. 

4.4.4.2 Integrity checking of NAS signalling messages in the UE 

Except the messages listed below, no NAS signalling messages shall be processed by the receiving EMM entity in the 
UE or forwarded to the ESM entity, unless the secure exchange of NAS messages has been estabUshed for the NAS 
signalling connection: 

- EMM messages: 

- IDENTITY REQUEST (if requested identification parameter is IMSI) ; 

- AUTHENTICATION REQUEST; 

- AUTHENTICATION REJECT; 

- ATTACH REJECT; 

- DETACH REQUEST; 

- DETACH ACCEPT (for non switch off); 

- TRACKING AREA UPDATE REJECT; 

- SERVICE REJECT. 

NOTE: These messages are accepted by the UE without integrity protection, as in certain situations they are sent 
by the network before security can be activated. 

AH ESM messages are integrity protected. 

Once the secure exchange of NAS messages has been estabUshed, the receiving EMM or ESM entity in the UE shall not 

process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If NAS 
signalling messages, having not successfully passed the integrity check, are received, then the NAS in the UE shall 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 



26 



ETSI TS 124 301 V8.2.1 (2009-06) 



discard that message. If any NAS signalling message is received as not integrity protected even though the secure 
exchange of NAS messages has been established by the network, then the NAS shall discard this message. 

4.4.4.3 Integrity checking of NAS signalling messages in the MME 

Except the messages listed below, no NAS signalling messages shall be processed by the receiving EMM entity in the 
MME or forwarded to the ESM entity, unless the secure exchange of NAS messages has been established for the NAS 
signalling connection: 

EMM messages: 

- ATTACH REQUEST; 

- IDENTITY RESPONSE (if requested identification parameter is IMSI) ; 

- AUTHENTICATION RESPONSE; 

- AUTHENTICATION FAILURE; 

- SECURITY MODE REJECT; 

- DETACH REQUEST; 

- DETACH ACCEPT; 

- TRACKING AREA UPDATE REQUEST. 

NOTE 1: The TRACKING AREA UPDATE REQUEST message is sent by the UE without integrity protection, if 
the tracking area updating procedure is initiated due to an inter-system change in idle mode and no 
current EPS security context is available in the UE. The other messages are accepted by the MME 
without integrity protection, as in certain situations they are sent by the UE before security can be 

activated. 

All ESM messages are integrity protected except a PDN CONNECTIVITY REQUEST message if it is sent 
piggybacked in ATTACH REQUEST message and NAS security is not activated. 

Once a current EPS security context exists, until the secure exchange of NAS messages has been established for the 
NAS signalling connection, the receiving EMM entity in the MME shall process the following NAS signalling 
messages, even if the MAC included in the message fails the integrity check or cannot be verified, as the EPS security 
context is not available in the network: 

- ATTACH REQUEST; 

- IDENTITY RESPONSE (if requested identification parameter is IMSI); 

- AUTHENTICATION RESPONSE; 

- AUTHENTICATION FAILURE; 

- SECURITY MODE REJECT; 

- DETACH REQUEST (if sent before security has been activated) ; 

- DETACH ACCEPT; 

- TRACKING AREA UPDATE REQUEST; 

- SERVICE REQUEST; 

- EXTENDED SERVICE REQUEST. 

NOTE 2: These messages are processed by the MME even when the MAC that fails the integrity check or cannot 
be verified, as in certain situations they can be sent by the UE protected with an EPS security context that 
is no longer available in the network. 

If an ATTACH REQUEST message fails the integrity check, the MME shall authenticate the subscriber before 
processing the attach request any further. 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 



27 



ETSI TS 124 301 V8.2.1 (2009-06) 



If a TRACKING AREA UPDATE REQUEST message fails the integrity check, the MME shall initiate a security mode 
control procedure to take a new mapped EPS security context into use, if the UE provided a nonceuE, GPRS ciphering 
key sequence number, P-TMSI and RAI in the TRACKING AREA UPDATE REQUEST message; otherwise the MME 
shall reject the request with EMM cause #9 "UE identity cannot be derived by the network". 

If a SERVICE REQUEST or EXTENDED SERVICE REQUEST message fails the integrity check, the MME shall 
reject the request with EMM cause #9 "UE identity cannot be derived by the network". 

Once the secure exchange of NAS messages has been estabhshed for the NAS signalling connection, the receiving 
EMM or ESM entity in the MME shall not process any NAS signalling messages unless they have been successfully 
integrity checked by the NAS. If any NAS signalling message, having not successfully passed the integrity check, is 
received, then the NAS in the MME shall discard that message. If any NAS signalling message is received, as not 
integrity protected even though the secure exchange of NAS messages has been established, then the NAS shall discard 
this message. 

4.4.5 Ciphering of NAS signalling messages 

The use of ciphering in a network is an operator option subject to MME configuration. When operation of the network 
without ciphering is configured, the MME shall indicate the use of "null ciphering algorithm" EEAO (see 
subclause 9.9.3.23) in the current security context for all UEs. For setting the security header type in outbound NAS 
messages, the UE and the MME shall apply the same rules irrespective of whether the "null ciphering algorithm" or any 
other ciphering algorithm is indicated in the security context. 

When the UE establishes a new NAS signalling connection, it shall send the initial NAS message unciphered. 

The UE shall start the ciphering and deciphering of NAS messages when the secure exchange of NAS messages has 
been estabhshed for a NAS signalUng connection. From this time onward, except for the ATTACH REQUEST message 
and TRACKING AREA UPDATE REQUEST message, the UE shall send all NAS messages ciphered until the NAS 
signalling connection is released, or the UE performs intersystem handover to A/Gb mode or lu mode. 

The MME shall start ciphering and deciphering of NAS messages as described in subclause 4.4.2.2. From this time 
onward, except for the SECURITY MODE COMMAND message, the MME shall send all NAS messages ciphered 
until the NAS signalUng connection is released, or the UE performs intersystem handover to A/Gb mode or lu mode. 

Details of ciphering and deciphering of NAS signalUng messages are specified in 3GPP TS 33.401 [19]. 



5 Elementary procedures for EPS mobility 
management 

5.1 Overview 
5.1.1 General 

This clause describes the procedures used for mobility management for EPS services (EMM) at the radio interface 
(reference point "LTE-Uu"). 

The main function of the mobility management sublayer is to support the mobility of a user equipment, such as 
informing the network of its present location and providing user identity confidentiality. 

A further function of the mobiUty management sublayer is to provide connection management services to the session 
management (SM) sublayer and the short message services (SMS) entity of the connection management (CM) sublayer. 

All the EMM procedures described in this clause can only be performed if a NAS signalling connection has been 
estabhshed between the UE and the network. Else, the EMM sublayer has to initiate the establishment of a NAS 
signaUing connection (see 3GPP TS 36.331 [22]). 
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5.1 .2 Types of EMM procedures 

Depending on how they can be initiated, three types of EMM procedures can be distinguished: 

1) EMM common procedures: 

An EMM common procedure can always be initiated whilst a NAS signalling connection exists. The procedures 
belonging to this type are: 

Initiated by the network: 

GUTI reallocation; 

- authentication; 

- security mode control; 

- identification; 
EMM information. 

2) EMM specific procedures: 

At any time only one UE initiated EMM specific procedure can be nmning. The procedures belonging to this 
type are: 

Initiated by the UE and used to attach the IMSI in the network for EPS services and/or non-EPS services, and 
to estabhsh an EMM context and a default bearer: 

- attach and combined attach. 

Initiated by the UE or the network and used to detach the IMSI in the network for EPS services and/or non- 
EPS services and to release an EMM context and all bearers: 

- detach or combined detach. 

Initiated by the UE when an EMM context has been established: 

- normal tracking area updating and combined tracking area updating (SI mode only); 

- periodic tracking area updating (SI mode only). 

The tracking area updating procedure can be used to request also the resource reservation for sending data. 

3) EMM connection management procedures (SI mode only): 

Initiated by the UE and used to establish a secure connection to the network or to request the resource 
reservation for sending data, or both: 

- service request. 

The service request procedure can only be initiated if no UE initiated EMM specific procedure is ongoing. 

Initiated by the network and used to request the estabhshment of a NAS signalhng connection or to prompt 
the UE to re-attach if necessary as a result of a network failure: 

- paging procedure. 

Initiated by the UE or the network and used to transport NAS messages: 

- transport of NAS messages. 

The transport of NAS messages procedure cannot be initiated while an EMM specific procedure is ongoing. 
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5.1 .3 EMM sublayer states 

5.1.3.1 General 

In the following subclauses, the EMM protocol of the UE and the network is described by means of two different state 
machines. In subclause 5.1.3.2, the states of the EMM entity in the UE are introduced. The behaviour of the UE 
depends on an EPS update status that is described in subclause 5.1.3.3. The states for the MME side are described in 
subclause 5.1.3.4. 

5.1 .3.2 EMM sublayer states in the UE 

5.1.3.2.1 General 

In the following subclauses, the possible EMM states of an EMM entity in the UE are described. Subclause 5.1.3.2.2 
summarizes the main states of an EMM entity. The substates that have been defined are described in subclause 5.1.3.2.3 
and subclause 5.1.3.2.4. 

It should be noted, however, that this subclause does not include a description of the detailed behaviour of the UE in the 
single states and does not cover abnormal cases. A detailed description of the behaviour of the UE is given in 
subclause 5.2. For the behaviour of the UE in abnormal cases refer to the description of the elementary EMM 
procedures in subclauses 5.4, 5.5, 5.6 and 5.7. 

5.1.3.2.2 Main states 

5.1.3.2.2.1 EMM-NULL 

The EPS capability is disabled in the UE. No EPS mobility management function shall be performed in this state. 

5.1.3.2.2.2 EMM-DEREGISTERED 

In the state EMM-DEREGISTERED, no EMM context has been established and the UE location is unknown to an 
MME and hence it is unreachable by an MME. In order to establish an EMM context, the UE shall start the attach or 
combined attach procedure (see subclause 5.5.1). 

5.1 .3.2.2.3 EMM-REGISTERED-INITIATED 

A UE enters the state EMM-REGISTERED-INITIATED after it has started the attach or the combined attach procedure 
and is waiting for a response from the MME (see subclause 5.5.1). 

5.1.3.2.2.4 EMM-REGISTERED 

In the state EMM-REGISTERED an EMM context has been established and a default EPS bearer context has been 
activated in the UE. When the UE is in EMM -IDLE mode, the UE location is known to the MME with an accuracy of a 
list of tracking areas containing a certain number of tracking areas. When the UE is in EMM-CONNECTED mode, the 
UE location is known to the MME with an accuracy of a serving eNodeB. The UE may initiate sending and receiving 
user data and signalling information and reply to paging. Additionally, tracking area updating or combined tracking area 
updating procedure is performed (see subclause 5.5.3). 

5.1 .3.2.2.5 EMM-DEREGISTERED-INITIATED 

A UE enters the state EMM-DEREGISTERED-INITIATED after it has requested release of the EMM context by 
starting the detach or combined detach procedure and is waiting for a response from the MME (see subclause 5.5.2). 

5.1 .3.2.2.6 EMM-TRACKING-AREA-UPDATING-INITIATED 

A UE enters the state EMM-TRACKING-AREA-UPDATING-INITIATED after it has started the tracking area 
updating or combined tracking area updatingprocedure and is waiting for a response from the MME (see 
subclause 5.5.3). 
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5.1.3.2.2.7 



EMM-SERVICE-REQUEST-INITIATED 



A UE enters the state EMM-SERVICE-REQUEST-INITIATED after it has started the service request procedure and is 
waiting for a response from the MME (see subclause 5.6.1). 
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Figure 5.1.3.2.2.7.1: EMM main states in tlie UE 



5.1 .3.2.3 Substates of state EMM-DEREGISTERED 

5.1.3.2.3.1 General 

The state EMM-DEREGISTERED is subdivided into a number of substates as described in this subclause. VaUd 
subscriber data are available for the UE before it enters the substates, except for the substate EMM- 
DEREGISTERED.NO-IMSI. 



5.1 .3.2.3.2 EMM-DEREGISTERED.NORMAL-SERVICE 

The substate EMM -DEREGISTERED.NORMAL-SER VICE is chosen in the UE, if the EPS update status is EUl or 
EU2, in the meantime a cell has been selected and the PLMN or tracking area is not in the forbidden list. 

5.1 .3.2.3.3 EMM-DEREGISTERED.LIMITED-SERVICE 

The substate EMM-DEREGISTERED.LIMITED-SERVICE is chosen in the UE, if the EPS update status is EU3, and it 
is known that a selected cell is unable to provide normal service (e.g. the selected cell is in a forbidden PLMN, is in a 
forbidden tracking area or has a CSG ID not included in the UE's Allowed CSG list). 
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5.1 .3.2.3.4 EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH 

The substate EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH is chosen in the UE, if the EPS update status is 
EU2, and a previous attach was rejected. 

5.1 .3.2.3.5 EMM-DEREGISTERED.PLMN-SEARCH 

The substate EMM-DEREGISTERED.PLMN-SEARCH is chosen in the UE, if the UE with a valid USIM is switched 
on. 

5.1 .3.2.3.6 EMM-DEREGISTERED.NO-IMSI 

The substate EMM-DEREGISTERED.NO-IMSI is chosen in the UE, if the UE is switched on without a valid USIM 
inserted. 

5.1 .3.2.3.7 EMM-DEREGISTERED.ATTACH-NEEDED 

Valid subscriber data are available for the UE and for some reason an attach must be performed as soon as possible. 
This substate can be entered if the access class is blocked due to access class control, or if the network rejects the NAS 
signalling cormection establishment. 

5.1 .3.2.3.8 EMM-DEREGISTERED. NO-CELL-AVAILABLE 

No E-UTRAN cell can be selected. This substate is entered after a first intensive search failed when in substate EMM- 
DEREGISTERED.PLMN-SEARCH. Cells are searched for at a low rhythm. No EPS services are offered. 

5.1 .3.2.4 Substates of state EMM-REGISTERED 

5.1.3.2.4.1 General 

The state EMM-REGISTERED is subdivided into a number of substates as described in this subclause. 

5.1 .3.2.4.2 EMM-REGISTERED.NORMAL-SERVICE 

The substate EMM-REGISTERED.NORMAL-SERVICE is chosen by the UE as the primary substate when the UE 
enters the state EMM-REGISTERED. 

5.1 .3.2.4.3 EMM-REGISTERED.ATTEMPTING-TO-UPDATE 

The substate EMM-REGISTERED.ATTEMPTING-TO-UPDATE is chosen by the UE if the tracking area updating or 

combined tracking area updating procedure failed due to a missing response from the network. No EMM procedure 
except the tracking area updating or combined tracking area updating procedure shall be initiated by the UE in this 
substate. No data shall be sent or received. 

5.1 .3.2.4.4 EMM-REGISTERED.LIMITED-SERVICE 

The substate EMM-REGISTERED.LIMITED-SERVICE is chosen in the UE, if the cell the UE selected is known not 
to be able to provide normal service. 

5.1 .3.2.4.5 EMM-REGISTERED.PLMN-SEARCH 

The substate EMM-REGISTERED.PLMN-SEARCH is chosen in the UE, while the UE is searching for PLMNs. 

5.1 .3.2.4.6 EMM-REGISTERED.UPDATE-NEEDED 

The UE has to perform a tracking area updating or combined tracking area updating procedure, but access to the current 
cell is barred. This state can be entered if the access class is blocked due to access class control, or if the network rejects 
the NAS signalling connection establishment. No EMM procedure except tracking area updating or combined tracking 
area updating or service request as a response to paging shall be initiated by the UE in this substate. 
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5.1 .3.2.4.7 EMM-REGISTERED.NO-CELL-AVAILABLE 

E-UTRAN coverage has been lost. In this substate, the UE shall not initiate any EMM procedures except for cell and 
PLMN reselection. 

5.1 .3.2.4.8 EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM 

A combined attach procedure or a combined tracking area updating procedure was successful for EPS services only. 
User data and signalling information may be sent and received. 

5.1 .3.2.4.9 EMM-REGISTERED.IMSI-DETACH-INITIATED 

The UE performs a combined detach procedure for non-EPS services only (detach type "IMSI Detach"). This substate is 
entered if the UE is attached for EPS and non-EPS services and wants to detach for non-EPS services only. User data 
and signalling information may be sent and received. 

5.1.3.3 EPS update status 

In order to describe the detailed UE behaviour, the EPS update (EU) status pertaining to a specific subscriber is defined. 

The EPS update status is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, 
else in the non- volatile memory in the ME, as described in annex C. 

The EPS update status value is changed only after the execution of an attach or combined attach, network initiated 
detach, authentication, tracking area update or combined tracking area update or service request procedure. 

EUl: UPDATED 

The last attach or tracking area updating attempt was successful. 

EU2: NOT UPDATED 

The last attach, service request or tracking area updating attempt failed procedurally, i.e. no response or reject 
message was received from the MME. 

EU3: ROAMING NOT ALLOWED 

The last attach, service request or tracking area updating attempt was correctly performed, but the answer from 
the MME was negative (because of roaming or subscription restrictions). 

5.1 .3.4 EMM sublayer states in the MME 

5.1.3.4.1 EMM-DEREGISTERED 

In the state EMM-DEREGISTERED, the MME has no EMM context or the EMM Context is marked as detached. The 
UE is detached. The MME may answer to an attach or a combined attach procedure initiated by the UE (see 
subclause 5.5.1). 

5.1 .3.4.2 EMM-COMMON-PROCEDURE-INITIATED 

The MME enters the state EMM-COMMON-PROCEDURE-INITIATED, after it has started a conunon EMM 
procedure (see subclause 5.4) and is waiting for a response from the UE. 

5.1.3.4.3 EMM-REGISTERED 

In the state EMM-REGISTERED, an EMM context has been estabhshed and a default EPS bearer context has been 
activated in the MME. 

5.1 .3.4.4 EMM-DEREGISTERED-INITIATED 

The MME enters the state EMM-DEREGISTERED-INITIATED after it has started a detach procedure and is waiting 
for a response from the UE (see subclause 5.5.2). 
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Figure 5.1.3.4.4.1 : EMM main states in the MME 



5.1 .4 Coordination between ElVIIVI and GIVIIVI 

If GMM and EMM are both enabled, a UE capable of SI mode and A/Gb mode or lu mode or both shall maintain one 
conmion registration for GMM and EMM indicating whether the UE is registered for packet services or not. 

A UE that is not registered shall be in state GMM-DEREGISTERED and in state EMM-DEREGISTERED. 

If the UE performs a successful attach or combined attach procedure in SI mode, it shall enter substates GMM- 
REGISTERED.NO-CELL-AVAILABLE and EMM-REGISTERED.NORMAL-SERVICE. 

If the UE performs a successful GPRS attach or combined GPRS attach procedure in A/Gb or lu mode, it shall enter 
substates GMM-REGISTERED.NORMAL-SERVICE and EMM-REGISTERED.NO-CELL-AVAILABLE. 

After successful completion of routing area updating or combined routing area updating and tracking area updating or 
combined tracking area updating procedures in both S 1 mode and A/Gb or lu mode, if the network has indicated that 
ISR is activated, the UE shall maintain registration and related periodic update timers in both GMM and EMM. 

5.1 .5 Coordination between ElVIIVI and MM 

UEs that operate in CS/PS mode 1 or CS/PS mode 2 of operation shall use the combined EPS/IMSI attach procedure in 
order to attach to both EPS and non-EPS services. 

UEs that operate in CS/PS mode 1 or CS/PS mode 2 of operation and are already attached to both EPS and non-EPS 
services shall use the combined tracking area updating and periodic tracking area updating procedures. 

UEs that operate in CS/PS mode 1 or CS/PS mode 2 of operation and are already attached to both EPS and non-EPS 
services shall perform a combined detach procedure in order to detach for non-EPS services. 

UEs that operate in CS/PS mode 1 or CS/PS mode 2 of operation should not use any MM timers related to MM specific 
procedures (e.g. T3210, T3211, T3212, T3213) while camped on E-UTRAN, unless the re-activation of these timers is 
explicitly described. If the MM timers are already running, the UE should not react on the expiration of the timers. 
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5.2 Behaviour of the UE in state ElVIIVI-DEREGISTERED and 
state ElVIIVI-REGISTERED 

5.2.1 General 

In this subclause, the detailed behaviour of the UE in the states EMM-DEREGISTERED and EMM-REGISTERED is 
described. 

5.2.2 UE behaviour in state ElVIIVI-DEREGISTERED 

5.2.2.1 General 

The state EMM-DEREGISTERED is entered in the UE, when: 

- the detach or combined detach is performed either by the UE or by the MME (see subclause 5.5.2); 
the attach request is rejected by the MME (see subclause 5.5.1); 

- the tracking area update request is rejected by the MME (see subclause 5.5.3); 

- the service request procedure is rejected by the MME (see subclause 5.6.1); 

- the UE deactivates all EPS bearer contexts locally (see subclause 6.4.4.6); 

- the UE is switched on; or 

- when an inter-system change from SI mode to non-3GPP access is completed and the non-3GPP access network 
provides PDN cormectivity to the same EPC. 

In state EMM-DEREGISTERED, the UE shall behave according to the substate as explained in subclause 5.2.2.3. 

5.2.2.2 Primary substate selection 

5.2.2.2.1 Selection of the substate after power on 

When the UE is switched on, the substate shall be PLMN-SEARCH if the USIM is available and valid. See 
3GPP TS 23.122 [6] for further details. 

The substate chosen after PLMN-SEARCH, following power on is: 

- if no cell can be selected, the substate shall be NO-CELL-AVAILABLE; 

- if no USIM is present, the substate shall be NO-IMSI; 

- if a suitable cell has been found and the PLMN or tracking area is not in the forbidden list, then the substate shall 
be NORMAL-SERVICE; 

- if the selected cell is in a forbidden PLMN or a forbidden tracking area, then the UE shall enter the substate 
LIMITED-SERVICE; 

if the UE is in manual network selection mode and no cell of the selected PLMN has been found, the UE shall 
enter the substate NO-CELL- AVAILABLE; and 

- if the selected cell is a non-3GPP cell, the substate shall be NO-CELL- AVAILABLE. 

5.2.2.3 Detailed description of UE behaviour in state EMM-DEREGISTERED 

5.2.2.3.1 NORMAL-SERVICE 

The UE shall perform an attach or combined attach procedure. 
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5.2.2.3.2 LIMITED-SERVICE 

The UE shall perform an attach or combined attach procedure when entering a cell which provides normal service. 

5.2.2.3.3 ATTEMPTING-TO-ATTACH 

The UE shaU: 

- perform an attach or combined attach procedure on the expiry of timers T3411 or T3402; and 

perform an attach or combined attach procedure when the UE enters a new cell in a different tracking area, and 
the tracking area of the new cell is not in the list of forbidden tracking areas. 

5.2.2.3.4 PLMN-SEARCH 

The UE shall perform PLMN selection. If a new PLMN is selected, the UE shall reset the attach attempt counter and 
perform the attach or combined attach procedure (see subclause 5.5.1). 

5.2.2.3.5 NO-IMS! 

The UE shall only perform cell selection according to 3GPP TS 36.304 [21]. 

5.2.2.3.6 ATTACH-NEEDED 

The UE shall start the attach or combined attach procedure, if still needed, as soon as the access is allowed in the 
selected cell for one of the access classes of the UE. 

5.2.2.3.7 NO-CELL-AVAILABLE 

The UE shall perform cell selection according to 3GPP TS 36.304 [21] and choose an appropriate substate when a cell 
is found. When the lower layers indicate to prepare for an SlOl mode to SI mode handover and the PLMN identity of 
the target cell provided with this indication is not in one of forbidden PLMN lists, the UE shall enter substate 
NORMAL-SERVICE. 

NOTE: It is assumed that the UE can determine the PLMN identity of networks supporting cdma2000® HRPD 

access from the information broadcast over the radio interface. For the purpose of SlOl mode to SI mode 
handover, the UE can use the PLMN identity of the visited cdma2000® HRPD network also as PLMN 
identity of the target cell. 

5.2.2.4 Substate when back to state EMM-DEREGISTERED from another EMM 
state 

When returning to state EMM-DEREGISTERED, the UE shall select a cell as specified in 3GPP TS 36.304 [21]. 

The substate depends on the result of the cell selection procedure, the outcome of the previously performed EMM 
specific procedures, on the EPS update status of the UE, on the tracking area data stored in the UE and on the presence 
oftheUSlM: 

- If no cell has been found, the substate is NO-CELL-AVAILABLE, until a cell is found. 

- If no USIM is present or if the inserted USIM is considered invalid by the UE, the substate shall be NO-IMSI. 

- If the selected cell is in a tracking area where the UE is allowed to roam, the substate shall be NORMAL- 
SERVICE. 

- If an attach shall be performed (e.g. network requested re-attach), the substate shall be ATTEMPTING-TO- 
ATTACH. 

- If a PLMN reselection (according to 3GPP TS 23.122 [6]) is needed, the substate shall be PLMN-SEARCH. 

- If the selected cell is in a tracking area where the UE is not allowed to roam, the substate shall be LIMITED- 
SERVICE; and 
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- if the selected cell is a non-3GPP cell, the substate shall be NO-CELL- AVAILABLE. 

5.2.3 UE behaviour in state EMM-REGISTERED 

5.2.3.1 General 

The state EMM-REGISTERED is entered at the UE, when: 

the attach or combined attach procedure is performed by the UE (see subclause 5.5.1). 
In state EMM-REGISTERED, the UE shall behave according to the substate as explained in subclause 5.2.3.2. 

5.2.3.2 Detailed description of UE behaviour in state EMM-REGISTERED 

5.2.3.2.1 NORMAL-SERVICE 

TheUE: 

- shall perform normal, periodic and combined tracking area updating (see subclause 5.5.3); and 

- shall respond to paging. 

5.2.3.2.2 ATTEMPTING-TO-UPDATE 

TheUE: 

- shall not send any user data; 

- shall perform tracking area updating on the expiry of timers T341 1 or T3402; and 

- shall perform tracking area updating when the tracking area of the serving cell has changed and this tracking area 
is not in the hst of forbidden tracking areas. 

5.2.3.2.3 LIMITED-SERVICE 

The UE: 

- shall perform cell selection/reselection according to 3GPP TS 36.304 [21]; and 

- may respond to paging (with IMSI). 

5.2.3.2.4 PLMN-SEARCH 

The UE may enter this substate when it is in automatic network selection mode and the maximum allowed number of 
subsequently unsuccessful tracking area updating have been performed. The UE may also enter this substate as a result 
of a tracking area update rejected by the network (see subclause 5.5.3) or as a result of a service request rejected by the 
network (see subclause 5.6.1). If a new PLMN is selected, the UE shall reset the tracking area updating attempt counter 
and perform the tracking area updating or combined tracking area updating procedure (see subclause 5.5.3). 

5.2.3.2.5 UPDATE-NEEDED 

The UE: 

- shall not send any user data; 

- shall not send signalling information unless as a response to paging; 

- shall perform cell selection/reselection according to 3GPP TS 36.304 [21]; and 

- shall enter the appropriate new substate depending on the EPS update status as soon as the access is allowed in 
the selected cell for one of the access classes of the UE. 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 



37 



ETSI TS 124 301 V8.2.1 (2009-06) 



5.2.3.2.6 NO-CELL-AVAILABLE 

The UE shall perform cell selection/reselection according to 3GPP TS 36.304 [21]. 

5.2.3.2.7 ATTEMPTING-TO-UPDATE-MM 

The UE: 

- shall perform cell selection/reselection according to 3GPP TS 36.304 [21]; 

- shall be able to receive and transmit user data and signalling information; and 

shall perform combined tracking area updating procedure indicating "combined TA/LA updating with IMSl 
attach" on the expiry of timers T3411 or T3402 or when the UE enters a tracking area not in the hst of registered 
tracking areas. 

5.3 General on elementary EMM procedures 

5.3.1 EMM modes and NAS signalling connection 

5.3.1 .1 Establishment of the NAS signalling connection 

When the UE is in EMM-IDLE mode and needs to transmit an initial NAS message, the UE shall request the lower 
layer to establish a RRC connection. In this request to the lower layer the NAS shall provide to the lower layer the RRC 
estabUshment cause and the call type as specified in annex D of this specification. 

Initial NAS messages are: 

- ATTACH REQUEST; 

- DETACH REQUEST; 

- TRACKING AREA UPDATE REQUEST; 

- SERVICE REQUEST; and 

- EXTENDED SERVICE REQUEST. 

For the routing of the initial NAS message to the appropriate MME, the UE NAS provides the lower layers with either 
the S-TMSI or the registered globally unique MME identifier (GUMMEI) that consists of the PLMN ID, the MME 
group ID, and the MME code (see 3GPP TS 23.003 [2]). 

- When the UE is registered in the tracking area of the current cell during the NAS signalhng connection 
establishment, the UE NAS shall provide the lower layers with the S-TMSI, but shall not provide the registered 
MME identifier to the lower layers. Exceptionally, when the UE in EMM-IDLE mode initiates a tracking area 
updating or combined tracking area updating procedure for load balancing purposes, the UE NAS shall provide 
the lower layers with neither S-TMSI nor registered MME identifier. 

- When the UE is not registered in the tracking area of the current cell during the NAS signalling connection 
establishment, the UE NAS does not provide the lower layers with the S-TMSl. If the UE has a valid registered 
MME identifier from a previous registration, the UE NAS shall provide the lower layers with the registered 
MME identifier. 

In SI mode, when the RRC cormection has been established successfully, the UE shall enter EMM-CONNECTED 
mode and consider the NAS signalhng connection estabhshed. 

In S 101 mode, when the cdma2000® HRPD access network resources are available for timnelled NAS signalling, the 
UE shall enter EMM-CONNECTED mode and consider the S 101 mode NAS signalling cormection established. 

5.3.1 .2 Release of the NAS signalling connection 

The signalling procedure for the release of the NAS signalling connection is initiated by the network. 
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In S 1 mode, when the RRC connection has been released, the UE shall enter EMM-IDLE mode and consider the NAS 

signalling connection released. 

To allow the network to release the NAS signalling connection, the UE shall start the timer T3440 in the following 
cases: 

a) the UE receives any of the EMM cause values #11, #12, #13, #14 (not appUcable to the service request 
procedure) or #15; or 

b) the UE receives a TRACKING AREA UPDATE ACCEPT message and the UE has not set the "active" flag in 
the TRACKING AREA UPDATE REQUEST message and the tracking area updating or combined tracking area 

updating procedure has been initiated in EMM-IDLE mode. 

Upon expiry of T3440, the UE shall locally release the established NAS signalling connection. 
In case b, 

upon an indication from the lower layers that the user plane radio bearers are set up, the UE shall stop timer 
T3440 and may send uplink signalling via the existing NAS signalling connection or user data via the user plane 
bearers; or 

- upon receipt of a DETACH REQUEST message, the UE shall stop timer T3440 and respond to the network 
initiated detach as specified in subclause 5.5.2.3. 

In S 101 mode, when the cdma2000® HRPD radio access connection has been released, the UE shall enter EMM-IDLE 
mode and consider the S 101 mode NAS signalling connection released. 

5.3.2 Lists of forbidden tracl<ing areas 

The UE shall store a list of "forbidden tracking areas for roaming", as well as a list of "forbidden tracking areas for 
regional provision of service". These lists shall be erased when the UE is switched off or when the UICC containing the 
USIM is removed, and periodically (with a period in the range 12 to 24 hours). One or more tracking areas is removed 
from the list of "forbidden tracking areas for roaming" in the UE, as well as the list of "forbidden tracking areas for 
regional provision of service" if, after a subsequent procedure e.g. attach procedure, tracking area updating procedure 
and GUTI reallocation procedure, one or more tracking areas in the lists is received from the network. 

In SI mode, the UE shall update the suitable list whenever an ATTACH REJECT, TRACKING AREA UPDATE 
REJECT, SERVICE REJECT or DETACH REQUEST message is received with the EMM cause #12 "tracking area not 
allowed", #13 "roaming not allowed in this tracking area", or #15 "no suitable cells in tracking area". 

Each list shall accommodate 40 or more TAIs. When the list is full and a new entry has to be inserted, the oldest entry 
shall be deleted. 

5.3.3 List of forbidden PLMNs for attacli in S1 01 mode 

A UE supporting SlOl mode shall store a list of "forbidden PLMNs for attach in SlOl mode". The UE shall erase this 
list when the UE is switched off or when the USIM is removed. 

In SlOl mode, the UE shall add to the "forbidden PLMNs for attach in SlOl mode" list the PLMN identity provided 
with the indication from the lower layers to prepare for an SlOl mode to SI mode handover whenever an ATTACH 
REJECT message is received with the EMM cause #1 1 "PLMN not allowed", #13 "roaming not allowed in this tracking 
area", #12 "tracking area not allowed", or #15 "no suitable cells in tracking area". 

The maximum number of possible entries in the "forbidden PLMNs for attach in SlOl mode" Ust is implementation 
dependent, but the list shall acconnmodate at least one PLMN identity. When the list is full and a new PLMN identity 
has to be inserted, the UE shall delete the oldest PLMN identity. 

5.3.4 Equivalent PLMNs list 

The UE shall store a list of equivalent PLMNs. These PLMNs shall be regarded by the UE as equivalent to each other 
for PLMN selection and cell selection/re-selection. The same list is used by EMM, GMM and MM. 
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The UE shall update or delete this list at the end of each attach or combined attach or tracking area updating or 
combined tracking area updating procedure. The stored list consists of a list of equivalent PLMNs as downloaded by the 
network plus the PLMN code of the registered PLMN that downloaded the list. When the UE is switched off, it shall 
keep the stored Ust so that it can be used for PLMN selection after switch on. The UE shall delete the stored list if the 
USIM is removed. The maximum number of possible entries in the stored list is 16. 

5.3.5 Handling of the periodic tracl^ing area update timer and mobile 
reachable timer (S1 mode only) 

Periodic tracking area updating is used to periodically notify the availability of the UE to the network. The procedure is 
controlled in the UE by the periodic tracking area update timer (timer T3412). The value of timer T3412 is sent by the 
network to the UE in the ATTACH ACCEPT message and can be sent in the TRACKING AREA UPDATE ACCEPT 
message. The UE shall apply this value in all tracking areas of the list of tracking areas assigned to the UE, until a new 
value is received. 

The timer T3412 is reset and started with its initial value, when the UE goes from EMM-CONNECTED to EMM-IDLE 
mode. The timer T3412 is stopped when the UE enters EMM-CONNECTED mode or EMM-DEREGISTERED state. 

When timer T3412 expires, the periodic tracking area updating procedure shall be started and the timer shall be set to its 
initial value for the next start. 

If the UE is in another state than EMM-REGISTERED. NORMAL-SERVICE when the timer expires the periodic 
tracking area updating procedure is delayed until the UE returns to EMM-REGISTERED .NORMAL-SERVICE. 

If ISR is activated, the UE shall keep both the periodic tracking area update timer (timer T3412) and the periodic 
routeing area update timer (timer T3312). The two separate timers run in the UE for updating MME and SGSN 
independently. If the periodic tracking area update timer expires and the UE cannot initiate the tracking area updating 
procedure, as it is in state EMM-REGISTERED.NO-CELL-AVAILABLE, the UE shall start the E-UTRAN deactivate 
ISR timer T3423. The UE shall initiate the tracking area updating procedure and stop the timer T3423 when it enters 
state EMM-REGISTERED.NORMAL-SERVICE before timer T3423 expires. After expiry of timer T3423 the UE shall 
set its TIN to "P-TMSl" in order to initiate the tracking area updating procedure when it returns to state EMM- 
REGISTERED.NORMAL-SERVICE. 

If the UE is attached to both EPS and non-EPS services, and if timer T3412 expires or timer T3423 expires when the 
UE is in EMM-REGISTERED.NO-CELL-AVAILABLE state, then the UE shall initiate the combined tracking area 
updating procedure indicating "Combined TA/LA updating with IMSI attach" when the UE returns to EMM- 
REGISTERED.NORMAL-SERVICE state. 

The network supervises the periodic tracking area updating procedure of the UE by means of the mobile reachable 
timer. The mobile reachable timer shall be longer than T3412. By default, the mobile reachable timer is 4 minutes 
greater than T3412. If ISR is not activated, the network behaviour upon expiry of the mobile reachable timer is network 
dependent, but typically the network stops sending paging messages to the UE on the first expiry, and may take other 
appropriate actions. 

The mobile reachable timer shall be reset and started with its initial value, when the MME releases the NAS signalling 
connection for the UE. The mobile reachable timer shall be stopped when a NAS signalling connection is established 
for the UE. 

Upon expiry of the mobile reachable timer the network shall start the implicit detach timer. The value of the implicit 
detach timer is network dependent. If ISR is activated, the default value of the impUcit detach timer is 4 minutes greater 
than T3423. If the implicit detach timer expires before the UE contacts the network, the network shall implicitly detach 
theUE. 

The implicit detach timer shall be stopped when a NAS signalling connection is established for the UE. 

5.3.6 Handling of timer T3402 

The value of timer T3402 can be sent by the network to the UE in the ATTACH ACCEPT message and TRACKING 
AREA UPDATE ACCEPT message. The UE shall apply this value in all tracking areas of the list of tracking areas 
assigned to the UE, until a new value is received, or until one of the above messages is received without a value 
specified, in which case the default value applies. 
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5.3.7 Handling of the Local Emergency Numbers List 

The Local Emergency Numbers List contains additional emergency numbers used by the serving network. The list can 
be downloaded by the network to the UE at successful registration and subsequent registration updates. There is only 
one Local Emergency Numbers List in the UE, and it can be updated with EMM procedures if the UE is in SI mode 
and with GMM and MM procedures if the the UE is in A/Gb or lu mode. 

The UE shall use the stored Local Emergency Numbers List received from the network in addition to the emergency 
numbers stored on the USIM or user equipment to detect that the number dialled is an emergency number. 

NOTE: The user equipment may use the emergency numbers list to assist the end user in determining whether the 
dialled number is intended for an emergency service or for another destination, e.g. a local directory 
service. The possible interactions with the end user are implementation specific. 

The network may send a Local Emergency Numbers List in the ATTACH ACCEPT or in the TRACKING AREA 
UPDATE ACCEPT messages, by including the Emergency Number List IE. The user equipment shall store the Local 
Emergency Numbers List, as provided by the network, except that any emergency number that is already stored in the 
USIM shall be removed from the Local Emergency Numbers List before it is stored by the user equipment. If there are 
no emergency numbers stored on the USIM, then before storing the received Local Emergency Numbers List, the user 
equipment shall remove from the Local Emergency Numbers List any emergency number stored permanently in the 
user equipment for use in this case (see 3GPP TS 22. 101 [8]). The Local Emergency Numbers List stored in the user 
equipment shall be replaced on each receipt of a new Emergency Number List IE. 

The emergency number(s) received in the Emergency Number List IE are valid only in networks with the same MCC as 
in the cell on which this IE is received. If no Local Emergency Numbers List is contained in the ATTACH ACCEPT or 
in the TRACKING AREA UPDATE ACCEPT message, then the stored Local Emergency Numbers List in the user 
equipment shall be kept, except if the user equipment has successfully registered to a PLMN with an MCC different 
from that of the last registered PLMN. 

The Local Emergency Numbers List shall be deleted at switch off and removal of the USIM. The user equipment shall 
be able to store up to ten local emergency numbers received from the network. 

5.3.8 Abnormal cases in the UE 

The following abnormal case can be identified: 

a) EMM uplink message transmission failure indication by lower layers 

When it is specified in the relevant procedure that it is up to the UE implementation to rerun the ongoing 
procedure that triggered that procedure, the procedure can typically be re-initiated using a retransmission 

mechanism of the uplink message (the one that has previously failed to be transmitted) with new sequence 
number and message authentication code information thus avoiding to restart the whole procedure. 

5.4 ElVIIVI common procedures 

5.4.1 GUTI reallocation procedure 
5.4.1.1 General 

The purpose of the GUTI reallocation procedure is to allocate a GUTI and optionally to provide a new TAI list to a 
particular UE. 

The reallocation of a GUTI is performed by the unique procedure defined in this subclause. This procedure can only be 
initiated by the MME in state EMM-REGISTERED. 

The GUTI can also be implicitly reallocated at attach or tracking area updating procedures. The implicit reallocation of 
a GUTI is described in the subclauses which specify these procedures (see subclause 5.5.1 and 5.5.3). 

The PLMN identity in the GUTI indicates the current registered PLMN. 

NOTE 1 : The GUTI reallocation procedme is usually performed in ciphered mode. 
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NOTE 2: Normally, the GUTI reallocation will take place in conjimction with another mobility management 
procedure, e.g. as part of tracking area updating. 



5.4.1.2 



GUTI reallocation initiation by the network 



The MME shall initiate the GUTI reallocation procedure by sending a GUTI REALLOCATION COMMAND message 
to the UE and starting the timer T3450 (see example in figure 5.4.1.2.1). 

The GUn REALLOCATION COMMAND message shall include a GUTI and may include a TAI Ust. 



UE 



MME 



GUTI REALLOCATION COMMAND 



Start T3450 



GUTI REALLOCATION COMPLETE 



Stop T3450 



Figure 5.4.1.2.1: GUT! reaiiocation procedure 



5.4.1 .3 GUTI reallocation completion by the UE 

Upon receipt of the GUTI REALLOCATION COMMAND message, the UE shall store the GUTI and the TAI Ust, and 
send a GUTI REALLOCATION COMPLETE message to the MME. The UE considers the new GUTI as vahd and the 
old GUTI as invalid. If the UE receives a new TAI list in the GUTI REALLOCATION COMMAND message, the UE 
shall consider the new TAI Ust as vaUd and the old TAI list as invalid; otherwise, the UE shall consider the old TAI Ust 
as valid 



5.4.1 .4 GUTI reallocation completion by the network 

Upon receipt of the GUTI REALLOCATION COMPLETE message, the MME shall stop the timer T3450 and consider 
the new GUTI as vaUd and the old GUTI as invaUd. If a new TAI Ust is provided in the GUTI REALLOCATION 
COMMAND message, the MME shall consider the new TAI list as valid and the old TAI list as invalid. 



5.4.1 .5 Abnormal cases in the UE 

The following abnormal cases can be identified: 

a) Transmission failure of GUTI REALLOCATION COMPLETE message indication with TAI change from lower 

layers 

If the current TAI is not in the TAI list, the GUTI reallocation procedure shall be aborted and a tracking area 
updating procedure shall be initiated. 

If the current TAI is still part of the TAI list, it is up to the UE implementation how to re-run the ongoing 
procedure that triggered the GUTI reaUocation procedure. 

b) Transmission failure of GUTI REALLOCATION COMPLETE message indication without TAI change from 
lower layers 

It is up to the UE implementation how to re-run the ongoing procedure that triggered the GUTI reaUocation 
procedure. 



5.4.1 .6 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) Lower layer failure 
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If a lower layer failure is detected before the GUTI REALLOCATION COMPLETE message is received, the old 
and the new GUTI shall be considered as valid until the old GUTI can be considered as invalid by the network. 
If a new TAI list was provided in the GUTI REALLOCATION COMMAND message, the old and new TAI list 
shall also be considered as valid until the old TAI list can be considered as invahd by the network. 

During this period the network: 

may first use the old S-TMSI from the old GUTI for paging within the area defined by the old TAI list for an 
implementation dependent number of paging attempts for network originated transactions. If a new TAI list 
was provided with old GUTI in the GUTI REALLOCATION COMMAND message, the new TAI list should 
also be used for paging. Upon response from the UE, the network may re-initiate the GUTI reallocation. If 
the response is received from a tracking area within the old and new TAI hst, the network shall re-initiate the 
GUTI reallocation. If no response is received to the paging attempts, the network may use the new S-TMSI 
from the new GUTI for paging for an implementation dependent number of paging attempts. In this case, if a 
new TAI list was provided with new GUTI in the GUTI REALLOCAITON COMMAND message, the new 
TAI list shall be used instead of the old TAI Ust. Upon response from the UE the network shall consider the 
new GUTI as vaUd and the old GUTI as invahd. 

The network may use the IMSI for paging if it needs to establish a NAS signalling connection as described in 
subclause 5.6.2.2.2. Upon response from the UE the GUTI reallocation is restarted; 

- shall consider the new GUTI as valid if it is used by the UE and, additionally, the new TAI hst as vahd if it 
was provided wdth this GUTI in the GUTI REALLOCATION COMMAND message; and 

may use the identification procedure followed by a new GUTI reallocation if the UE uses the old GUTI. 

b) Expiry of timer T3450 

The GUTI reallocation procedure is supervised by the timer T3450. The network shall, on the first expiry of 
timer T3450, reset and restart timer T3450 and shall retransmit the GUTI REALLOCATION COMMAND. This 
retransmission is repeated four times, i.e. on the fifth expiry of timer T3450, the network shall abort the 
reallocation procedure and shall follow the rules described for case a above. 

c) GUTI reallocation and attach procedure colUsion 

If the network receives an ATTACH REQUEST message before the ongoing GUTI reallocation procedure has 
been completed the network shall proceed with the attach procedure after deletion of the EMM context. 

d) GUTI reallocation and UE initiated detach procedure colhsion 

If the network receives a DETACH REQUEST message before the ongoing GUTI reallocation procedure has 
been completed, the network shall abort the GUTI reallocation procedure and shall progress the detach 
procedure. 

e) GUTI reallocation and tracking area updating procedure collision 

If the network receives a TRACKING AREA UPDATE REQUEST message before the ongoing GUTI 
reallocation procedure has been completed, the network shall abort the GUTI reallocation procedure and shall 
progress the tracking area updating procedure. The network may then perform a new GUTI reallocation. 

f) GUTI reallocation and service request procedure colUsion 

If the network receives an EXTENDED SERVICE REQUEST message before the ongoing GUTI reallocation 
procedure has been completed, the network shall progress both procedures. 

g) Lower layer indication of non-dehvered NAS PDU due to handover 

If the GUTI REALLOCATION COMMAND message could not be delivered due to an intra MME handover 
and the target TA is included in the TAI list, then upon successful completion of the intra MME handover the 
MME shall retransmit the GUTI REALLOCATION COMMAND message. If a failure of the handover 
procedure is reported by the lower layer and the S 1 signalUng connection exists, the MME shall retransmit the 
GUTI REALLOCATION COMMAND message. 

If there is a different new GUTI and optionally a new TAI list included in a subsequent GUTI REALLOCATION 
COMMAND message, the UE always regards the newest GUTI and the newest TAI list as vaUd for the recovery time. 
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5.4.2 Authentication procedure 

5.4.2.1 General 

The purpose of the EPS authentication and key agreement (AKA) procedure is to provide mutual authentication 
between the user and the network and to agree on a key Kasme (see 3GPP TS 33.401 [19J). The cases when the EPS 
AKA procedure should be used are defined in 3GPP TS 33.401 [19]. 

The EPS AKA procedure is always initiated and controlled by the network. However, the UE can reject the EPS 
authentication challenge sent by the network. 

The UE shall support the EPS authentication challenge only if a USIM is present. 

An EPS security context is established in the UE and the network when an EPS authentication is successfully 
performed. During a successful EPS authentication, the CK and IK keys are computed. CK and IK are then used as key 
material to compute a new key, Kasme. Kasme is stored in the EPS security contexts (see 3GPP TS 33.401 [19]) of both 
the network and the UE, and is the root for the EPS integrity protection and ciphering key hierarchy. 

5.4.2.2 Authentication initiation by the network 

When a NAS signalling connection exists, the network can initiate an authentication procedure at any time. The 
network initiates the authentication procedure by sending an AUTHENTICATION REQUEST message to the UE and 
starting the timer T3460 (see example in figure 5.4.2.2.1). The AUTHENTICATION REQUEST message contains the 
parameters necessary to calculate the authentication response (see 3GPP TS 33.401 [19]). 

UE MME 



AUTHENTICATION REQUEST ^ -.-o-o^ 

Start T3460 



AUTHENTICATION RESPONSE ^ g^^p 73450 



AUTHENTICATION REJECT 'f. 

authentication 



failed 

Figure 5.4.2.2.1 : Authentication procedure 

5.4.2.3 Authentication response by the UE 

The UE shall respond to an AUTHENTICATION REQUEST message. With the exception of the cases described in 
subclause 5.4.2.6, the UE shall process the authentication challenge data and respond with an AUTHENTICATION 
RESPONSE message to the network. 

Upon a successful EPS authentication challenge, the new Kasme calculated from the authentication challenge data shall 
be stored in a new EPS security context. 

The USIM will compute the authentication response (RES) using the authentication challenge data received from the 
ME, and pass RES to the ME. 

In order to avoid a synchronisation failure, when the UE receives an AUTHENTICATION REQUEST message, the UE 
shall store the received RAND together with the RES returned from the USIM in the volatile memory. When the UE 
receives a subsequent AUTHENTICATION REQUEST message, if the stored RAND value is equal to the new 
received value in the AUTHENTICATION REQUEST message, then the UE shall not pass the RAND to the USIM, 
but shall send the AUTHENTICATION RESPONSE message with the stored RES. If there is no valid stored RAND in 
the UE or the stored RAND is different from the new received value in the AUTHENTICATION REQUEST message. 
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the UE shall pass the RAND to the USIM, shall override any previously stored RAND and RES with the new ones and 

start, or reset and restart timer T3416. 

The RAND and RES values stored in the UE shall be deleted and timer T3416, if running, shall be stopped: 

- upon receipt of a 

- SECURITY MODE COMMAND, 

- SERVICE REJECT, 

- TRACKING AREA UPDATE ACCEPT, or 

- AUTHENTICATION REJECT message; 
upon expiry of timer T3416; or 

- if the UE enters the EMM state EMM-DEREGISTERED or EMM-NULL. 

5.4.2.4 Authentication completion by tine network 

Upon receipt of an AUTHENTICATION RESPONSE message, the network stops the timer T3460 and checks the 
correctness of RES (see 3GPP TS 33.401 [19]). 

If the authentication procedure has been completed successfully and the related eKSl is stored in the EPS security 
context of the network, the network shall include a different eKSI value in the AUTHENTICATION REQUEST 
message when it initiates a new authentication procedure. 

Upon receipt of an AUTHENTICATION FAILURE message, the network stops the timer T3460. In the case where the 
EMM cause #21 "synch failure" is received, the core network may renegotiate with the HSS/AuC and provide the UE 
with new authentication parameters. 

5.4.2.5 Autlientication not accepted by tlie network 

If the authentication response returned by the UE is not vahd, the network response depends upon the type of identity 
used by the UE in the initial NAS message, that is: 

- if the GUTI was used; or 

- if the IMSl was used. 

If the GUTI was used, the network should initiate an identification procedure. If the IMSl given by the UE during the 
identification procedure differs from the IMSl the network had associated with the GUTI, the authentication should be 
restarted with the correct parameters. Otherwise, if the IMSl provided by the UE is the same as the IMSl stored in the 
network (i.e. authentication has really failed), the network should proceed as described below. 

If the IMSl was used for identification in the initial NAS message, or the network decides not to initiate the 
identification procedure after an unsuccessful authentication procedure, the network should send an 
AUTHENTICATION REJECT message to the UE. 

Upon receipt of an AUTHENTICATION REJECT message, the UE shall set the update status to EU3 ROAMING NOT 
ALLOWED, delete the stored GUTI, TAI list, last visited registered TAI and KSIasme- The USIM shall be considered 
invaUd until switching off the UE or the UICC containing the USIM is removed. 

If the AUTHENTICATION REJECT message is received by the UE, the UE shall abort any EMM signalling 
procedure, stop any of the timers T3410, T3417 or T3430 (if running) and enter state EMM-DEREGISTERED. 

5.4.2.6 Authentication not accepted by the UE 

In an EPS authentication challenge, the UE shall check the authenticity of the core network by means of the AUTN 
parameter received in the AUTHENTICATION REQUEST message. This enables the UE to detect a false network. 

During an EPS authentication procedure, the UE may reject the core network due to an incorrect AUTN parameter (see 
3GPP TS 33.401 [19]). This parameter contains three possible causes for authentication failure: 
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a) MAC code failure: 

If the UE finds the MAC code (supplied by the core network in the AUTN parameter) to be invalid, the UE 
shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #20 "MAC 
failure". The UE shall then follow the procedure described in subclause 5.4.2.7, item c. 

b) Non-EPS authentication unacceptable: 

If the UE finds that the "separation bit" in the AMF field of AUTN supphed by the core network is 0, the UE 
shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #26 "Non-EPS 
authentication unacceptable" (see subclause 6.1.1 in 3GPP TS 33.401 [19]). The UE shall then follow the 
procedure described in subclause 5.4.2.7, item d. 

c) SQN failure: 

If the UE finds the SQN (supplied by the core network in the AUTN parameter) to be out of range, the UE 
shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #21 "synch 
failure" and a re-synchronization token AUTS provided by the USIM (see 3GPP TS 33.102 [18]). The UE 
shall then follow the procedure described in subclause 5.4.2.7, item d. 

If the UE returns an AUTHENTICATION FAILURE message to the network, the UE shall delete any previously stored 
RAND and RES and shall stop timer T3416, if running. 

5.4.2.7 Abnormal cases 

a) Lower layer failure: 

Upon detection of lower layer failure before the AUTHENTICATION RESPONSE is received, the network 
shall abort the procedure. 

b) Expiry of timer T3460: 

The network shall, on the first expiry of the timer T3460, retransmit the AUTHENTICATION REQUEST 

message and shall reset and start timer T3460. This retransmission is repeated four times, i.e. on the fifth expiry 
of timer T3460, the network shall abort the authentication procedme and any ongoing EMM specific procedure 
and release the NAS signalling connection. 

c) Authentication failure (EMM cause #20 "MAC failure"): 

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #20 "MAC failure" according 
to subclause 5.4.2.6, to the network and start timer T3418 (see example in figure 5.4.2.7.1). Furthermore, the UE 
shall stop any of the retransmission timers that are ruiming (e.g. T3410, T3417, T3421 or T3430). Upon the first 
receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #20 "MAC failure", the 
network may initiate the identification procedure described in subclause 5.4.4. This is to allow the network to 
obtain the IMSI from the UE. The network may then check that the GUTI originally used in the authentication 
challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY REQUEST message from the 
network, the UE shall send the IDENTITY RESPONSE message. 

NOTE 1: Upon receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #20 "MAC 
failure", the network may also terminate the authentication procedure (see subclause 5.4.2.5). 

If the GUTI/IMSI mapping in the network was incorrect, the network should respond by sending a new 
AUTHENTICATION REQUEST message to the UE. Upon receiving the new AUTHENTICATION REQUEST 
message from the network, the UE shall stop the timer T3418, if running, and then process the challenge 
information as normal. 

If the network is validated successfully (an AUTHENTICATION REQUEST that contains a valid SQN and 
MAC is received), the UE shall send the AUTHENTICATION RESPONSE message to the network and shall 
start any retransmission timers (e.g. T3410, T3417, T3421 or T3430) if they were running and stopped when the 
UE received the first failed AUTHENTICATION REQUEST message. 

If the UE receives the second AUTHENTICATION REQUEST while T3418 is running, and the MAC value 
cannot be resolved or the message contains an EPS authentication challenge, the UE shall follow the procedure 
specified in this subclause, item c, starting again from the begiiming. If the SQN is invalid, the UE shall proceed 
as specified in item e. 
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It can be assumed that the source of the authentication challenge is not genuine (authentication not accepted by 

the UE) if any of the following occur: 

- after sending the AUTHENTICATION FAILURE message with the EMM cause #20 "MAC failure" the 
timer T3418 expires; 

- the UE detects any combination of the authentication failures: EMM causes #20 "MAC failure" and #21 
"sync failure", during three consecutive authentication challenges. The authentication challenges shall be 
considered as consecutive only, if the authentication challenges causing the second and third authentication 
failure are received by the UE, while the timer T3418 or T3420 started after the previous authentication 
failure is running. 

When it has been deemed by the UE that the source of the authentication challenge is not genuine (i.e. 
authentication not accepted by the UE), the UE shall proceed as described in item f . 



UE MME 

AUTHENTICATION REQUEST 

M Start T3460 



AUTHENTICATION FAILURE (cause = "MAC failure") 
Start T34 18 ^ Stop T3460 



IDENTITY REQUEST 
IDENTITY RESPONSE (IMSI) 



Start T3470 
Stop T3470 



AUTHENTICATION REQUEST 
Stop T34 1 8 ^ Start T3460 



AUTHENTICATION RESPONSE 



Stop T3460 



Figure 5.4.2.7.1 : Authentication failure procedure (EMM cause #20 "MAC failure" or 
#26 "Non-EPS authentication unacceptable") 

d) Authentication failure (EMM cause #26 "Non-EPS authentication unacceptable"): 

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #26 "Non-EPS authentication 
unacceptable", to the network and start the timer T3418 (see example in figure 5.4.2.7.1). Furthermore, the UE 
shall stop any of the retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first 
receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #26 "Non-EPS 
authentication unacceptable", the network may initiate the identification procedure described in subclause 5.4.4. 
This is to allow the network to obtain the IMSI from the UE. The network may then check that the GUTI 
originally used in the authentication challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY 
REQUEST message from the network, the UE shall send the IDENTITY RESPONSE message. 

NOTE 2: Upon receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #26 "Non- 
EPS authentication unacceptable", the network may also terminate the authentication procedure (see 
subclause 5.4.2.5). 

If the GUTI/IMSI mapping in the network was incorrect, the network should respond by sending a new 
AUTHENTICATION REQUEST message to the UE. Upon receiving the new AUTHENTICATION REQUEST 
message from the network, the UE shall stop the timer T3418, if running, and then process the challenge 
information as normal. If the GUTI/IMSI mapping in the network was correct, the network terminates the 
authentication procedure (see subclause 5.4.2.5). 

e) Authentication failure (EMM cause #21 "synch failure"): 
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The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #21 "synch failure", to the 
network and start the timer T3420 (see example in figure 5.4.2.7.2). Furthermore, the UE shall stop any of the 
retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an 
AUTHENTICATION FAILURE message from the UE with the EMM cause #21 "synch failure", the network 
shall use the returned AUTS parameter from the authentication failure parameter IE in the AUTHENTICATION 
FAILURE message, to re-synchronise. The re-synchronisation procedure requires the MME to delete aU unused 
authentication vectors for that IMSI and obtain new vectors from the HSS. When re-synchronisation is complete, 
the network shall initiate the authentication procedure. Upon receipt of the AUTHENTICATION REQUEST 
message, the UE shall stop the timer T3420, if running. 

NOTE 3: Upon receipt of two consecutive AUTHENTICATION FAILURE messages from the UE with EMM 
cause #21 "synch failure", the network may terminate the authentication procedure by sending an 
AUTHENTICATION REJECT message. 

If the network is validated successfully (a new AUTHENTICATION REQUEST is received which contains a 
vaUd SQN and MAC) while T3420 is running, the UE shall send the AUTHENTICATION RESPONSE 

message to the network and shall start any retransmission timers (e.g. T3410, T3417, T3421 or T3430), if they 
were running and stopped when the UE received the first failed AUTHENTICATION REQUEST message. 

If the UE receives the second AUTHENTICATION REQUEST while T3420 is running, and the MAC value 
cannot be resolved or the message contains a EPS authentication challenge, the UE shall proceed as specified in 
item c; if the SQN is invalid, the UE shall follow the procedure specified in this subclause, item e, starting again 

from the beginning. 

The UE shall deem that the network has failed the authentication check and proceed as described in item f if any 
of the following occurs: 

the timer T3420 expires; 

- the UE detects any combination of the authentication failures: EMM cause #20 "MAC failure" or #21 "sync 
failure", during three consecutive authentication challenges. The authentication challenges shall be 
considered as consecutive only if the authentication challenges causing the second and third authentication 
failure are received by the UE while the timer T3418 or T3420 started after the previous authentication 
failure is running. 



UE MME 

AUTHENTICATION REQUEST 



AUTHENTICATION FAILURE (cause = "synch failure") 
Start T3420 ► 

AUTHENTICATION REQUEST 

Stop T3420 ^ 

AUTHENTICATION RESPONSE 



Figure 5.4.2.7.2: Authentication failure procedure (EMM cause #21 

f) Network failing the authentication check: 

If the UE deems that the network has failed the authentication check, then it shall request RRC to locally release 
the RRC connection and treat the active cell as barred (see 3GPP TS 36.331 [22]). The UE shall start any 
retransmission timers (e.g. T3410, T3417, T3421 or T3430), if they were running and stopped when the UE 
received the first AUTHENTICATION REQUEST message containing an invalid MAC or SQN. 



Start T3460 

Stop T3460 
Perform 
re-synch 
with HSS 
Start T3460 

Stop T3460 
"synch failure") 
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g) Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE 
message indication from lower layers (if the authentication procedure is triggered by a tracking area updating 
procedure) 

The UE shall re-initiate the tracking area updating procedure. 

h) Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE 
message indication with TAI change from lower layers (if the authentication procedure is triggered by a service 
request procedure) 

If the current TAI is not in the TAI list, the authentication procedure shall be aborted and a tracking area 

updating procedure shall be initiated. 

If the current TAI is still part of the TAI list, it is up to the UE implementation how to re-run the ongoing 
procedure that triggered the authentication procedure. 

i) Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE 
message indication without TAI change from lower layers (if the authentication procedure is triggered by a 
service request procedure) 

It is up to the UE implementation how to re-run the ongoing procedure that triggered the authentication 

procedure. 

j) Lower layers indication of non-delivered NAS PDU due to handover 

If the AUTHENTICATION REQUEST message could not be delivered due to an intra MME handover and the 
target TA is included in the TAI list, then upon successful completion of the intra MME handover the MME 
shall retransmit the AUTHENTICATION REQUEST message. If a failure of handover procedure is reported by 
the lower layer and the S 1 signalling connection exists, the MME shall retransmit the AUTHENTICATION 
REQUEST message. 

5.4.3 Security mode control procedure 

5.4.3.1 General 

The purpose of the NAS security mode control procedure is to take an EPS security context into use, and initialise and 
start NAS signalling security between the UE and the MME with the corresponding NAS keys and security algorithms. 

5.4.3.2 NAS security mode control initiation by the network 

The MME initiates the NAS security mode control procedure by sending a SECURITY MODE COMMAND message 
to the UE and starting timer T3460 (see example in figure 5.4.3.2.1). 

If the security mode control procedure is initiated further to a successful execution of the authentication procedure, the 
MME shall use the reset downlink NAS COUNT to integrity protect the SECURITY MODE COMMAND message. 

The MME shall send the SECURITY MODE COMMAND message vmciphered, but shall integrity protect the message 
with the NAS integrity key based on Kasme or mapped K'asme indicated by the eKSI included in the message. The 
MME shall set the security header type of the message to "integrity protected with new EPS security context". 

Upon receipt of a TRACKING AREA UPDATE REQUEST message including a GPRS ciphering key sequence 
number IE, if the MME does not have the valid current EPS security context indicated by the UE, the MME shall 
indicate the use of the new mapped EPS security context to the UE by setting the type of security context flag in the 
NAS key set identifier IE to "mapped security context" and the KSI value related to the security context of the source 
system. The MME shall use the reset downhnk NAS COUNT to integrity protect the SECURITY MODE COMMAND 
message. 

While having a mapped current EPS security context with the UE, if the MME wants to take the native EPS security 
context into use, the MME shall include the eKSI that matches the native EPS security context in the SECURITY 
MODE COMMAND message. 

The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to 
NAS, RRC and UP (user plane) ciphering as well as NAS, RRC integrity, and other possible target network security 
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capabilities, i.e. UTRAN/GERAN if UE included them in the message to network), the replayed nonceuE if the UE 
included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set 
Identifier (eKSI). 

Additionally, the MME may request the UE to include its IMEISV in the SECURITY MODE COMPLETE message. 

NOTE: The AS and NAS security capabilities will be the same, i.e. if the UE supports one algorithm for NAS it 
is also be supported for AS. 

UE MME 



SECURITY MODE COMMAND ^ r,.-,.^^ 
Start T3460 



SECURITY MODE COMPLETE ^ g^^p J3450 



OR 

SECURITY MODE REJECT 

► Stop T3460 
Figure 5.4.3.2.1 : Security mode control procedure 

5.4.3.3 NAS security mode command accepted by the UE 

Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode 
command can be accepted or not. This is done by performing the integrity check of the message and by checking that 
the received UE security capabilities and the received nonccuE have not been altered compared to what the UE provided 
in the initial layer 3 message that triggered this procedure. 

If the type of security context flag is set to "native security context" and if the KSI matches a valid native EPS security 
context held in the UE while the UE has a mapped EPS security context as the current security context, the UE shall 
take the native EPS security context into use. 

If the security mode command can be accepted, the UE shall reset the uplink NAS COUNT and the UE shall take the 
new EPS security context into use when: 

a) the SECURITY MODE COMMAND message is received further to a successful execution of the authentication 
procedure; or 

b) the type of security context flag is set to "mapped security context" in the NAS KSI IE included in the 
SECURITY MODE COMMAND message. 

If the security mode command can be accepted and the eKSI was included in the SECURITY MODE COMMAND 
message, the UE shall send a SECURITY MODE COMPLETE message integrity protected with the selected NAS 
integrity algorithm and the NAS integrity key based on the Kasme or mapped K'asme if the type of security context flag 
is set to "mapped security context" indicated by the eKSI. If the SECURITY MODE COMMAND message includes the 
type of security context flag set to "mapped security context" in the NAS KSI IE, nonccMME and nonccuE, the UE shall 
generate K'asme from both nonces as indicated in 3GPP TS 33.401 [19] and reset the downUnk NAS COUNT to check 
whether the SECURITY MODE COMMAND can be accepted or not. The UE shall cipher the SECURITY MODE 
COMPLETE message with the selected NAS ciphering algorithm and the NAS ciphering key based on the Kasme or 
mapped K'asme indicated by the eKSI. The UE shall set the security header type of the message to "integrity protected 
and ciphered with new EPS security context". 

From this time onward the UE shall cipher and integrity protect all NAS signalling messages with the selected NAS 
ciphering and NAS integrity algorithms. 

If the MME indicated in the SECURITY MODE COMMAND message that the IMEISV is requested, the UE shall 
include its IMEISV in the SECURITY MODE COMPLETE message. 
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5.4.3.4 NAS security mode control completion by the network 

The MME shall, upon receipt of the SECURITY MODE COMPLETE message, stop timer T3460. From this time 
onward the MME shall integrity protect and encipher aU signalhng messages with the selected NAS integrity and 
ciphering algorithms. 

5.4.3.5 NAS security mode command not accepted by the UE 

If the security mode command cannot be accepted, the UE shall send a SECURITY MODE REJECT message, which 
shall not be integrity protected. The SECURITY MODE REJECT message contains an EMM cause that typically 

indicates one of the following cause values: 

#23: UE security capabilities mismatch; 

#24: security mode rejected, unspecified. 

Upon receipt of the SECURITY MODE REJECT message, the MME shall stop timer T3460. The MME shall also abort 
the ongoing procedure that triggered the initiation of the NAS security mode control procedure. 

Both the UE and the MME shall revert to the EPS security context in use before the initiation of the security mode 
control procedure, if any. 

5.4.3.6 Abnormal cases in the UE 

The following abnormal cases can be identified: 

a) Transmission failure of SECURITY MODE COMPLETE message or SECURITY MODE REJECT message 
indication from lower layers (if the security mode control procedure is triggered by a tracking area updating 
procedure) 

The UE shall re-initiate the tracking area updating procedure. 

b) Transmission failure of SECURITY MODE COMPLETE message or SECURITY MODE REJECT message 
indication with TAI change from lower layers (if the security mode control procedure is triggered by a service 
request procedure) 

If the current TAI is not in the TAI list, the security mode control procedure shall be aborted and a tracking area 
updating procedure shall be initiated. 

If the current TAI is still part of the TAI list, it is up to the UE implementation how to re-run the ongoing 
procedure that triggered the security mode control procedure. 

c) Transmission failure of SECURITY MODE COMPLETE message or SECURITY MODE REJECT message 
indication without TAI change from lower layers (if the security mode control procedure is triggered by a service 
request procedure) 

It is up to the UE implementation how to re-run the ongoing procedure that triggered the security mode control 
procedure. 

5.4.3.7 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) Lower layer failure before the SECURITY MODE COMPLETE or SECURITY MODE REJECT message is 
received 

The network shall abort the procedure. 

b) Expiry of timer T3460 

The network shall, on the first expiry of the timer T3460, retransmit the SECURITY MODE COMMAND and 
shall reset and start timer T3460. This retransmission is repeated four times, i.e. on the fifth expiry of timer 
T3460, the procedure shall be aborted. 
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c) Collision between security mode control procedure and attach, service request, tracking area updating procedure 

or detacli procedure not indicating switch off 

The network shall abort the security mode control procedure and proceed with the UE initiated procedure. 

d) Collision between security mode control procedure and other EMM procedures than in item c 
The network shall progress both procedures. 

e) Lower layers indication of non-deUvered NAS PDU due to handover 

If the SECURITY MODE COMMAND message could not be delivered due to an intra MME handover and the 
target TA is included in the TAI list, then upon successful completion of the intra MME handover the MME 
shall retransmit the SECURITY MODE COMMAND message. If a failure of the handover procedure is reported 
by the lower layer and the SI signalhng connection exists, the MME shall retransmit the SECURITY MODE 
COMMAND message. 

5.4.4 Identification procedure 
5.4.4.1 General 

The identification procedure is used by the network to request a particular UE to provide specific identification 

parameters, e.g. the International Mobile Subscriber Identity (IMSI) or the International Mobile Equipment Identity 
(IMEI). IMEI and IMSI definition and structure are specified in 3GPP TS 23.003 [2]. 

For mobile device supporting both 3GPP access and cdma2000® access a single IMEI is used to identify the device as 
specified in 3GPP TS 22.278 [IB]. 



5.4.4.2 



Identification initiation by the network 



The network initiates the identification procedure by sending an IDENTITY REQUEST message to the UE and starting 
the timer T3470 (see example in figure 5.4.4.2.1). The IDENTITY REQUEST message specifies the requested 
identification parameters in the Identity type information element. 



UE 



MME 



IDENTITY REQUEST 



Start T3470 



IDENTITY RESPONSE 



Stop T3470 



Figure 5.4.4.2.1 : Identification procedure 



5.4.4.3 



Identification response by the UE 



A UE shall be ready to respond to an IDENTITY REQUEST message at any time whilst in EMM-CONNECTED 
mode. 

Upon receipt of the IDENTITY REQUEST message the UE shall send an IDENTITY RESPONSE message to the 
network. The IDENTITY RESPONSE message shall contain the identification parameters as requested by the network. 



5.4.4.4 Identification completion by the network 

Upon receipt of the IDENTITY RESPONSE the network shall stop the timer T3470. 
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5.4.4.5 Abnormal cases in the UE 

The following abnormal cases can be identified: 

a) Requested identity is not available 

If the UE cannot encode the requested identity in the IDENTITY RESPONSE message, e.g. because no vaUd 
USIM is available, then it shall encode the identity type as "No identity". 

b) Transmission failure of IDENTITY RESPONSE message indication from lower layers (if the identification 
procedure is triggered by a tracking area updating procedure) 

The UE shall re-initiate the tracking area updating procedure. 

5.4.4.6 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) Lower layer failure 

Upon detection of a lower layer failure before the IDENTITY RESPONSE is received, the network shall abort 

any ongoing EMM procedure. 

b) Expiry of timer T3470 

The identification procedure is supervised by the network by the timer T3470. The network shall, on the first 
expiry of the timer T3470, retransmit the IDENTITY REQUEST message and reset and restart the timer T3470. 
This retransmission is repeated four times, i.e. on the fifth expiry of timer T3470, the network shall abort the 
identification procedure and any ongoing EMM procedure. 

c) Collision of an identification procedure with an attach procedure 

If the network receives an ATTACH REQUEST message before the ongoing identification procedure has been 
completed and no attach procedure is pending on the network (i.e. no ATTACH ACCEPT/REJECT message has 
still to be sent as an answer to an ATTACH REQUEST message), the network shall proceed with the attach 
procedure. 

d) Collision of an identification procedure with an attach procedure when the identification procedure has been 
caused by an attach procedure 

If the network receives an ATTACH REQUEST message before the ongoing identification procedure has been 
completed and an attach procedure is pending (i.e. an ATTACH ACCEPT/REJECT message has to be sent as an 
answer to an earlier ATTACH REQUEST message), then: 

If one or more of the information elements in the ATTACH REQUEST message differ from the ones 
received within the previous ATTACH REQUEST message, the network shall proceed with the new attach 
procedure; or 

- If the information elements do not differ, then the network shall not treat any further this new ATTACH 
REQUEST. 

e) Collision of an identification procedure with a UE initiated detach procedure 

Detach containing cause "switch off" within the Detach type IE: 

If the network receives a DETACH REQUEST message before the ongoing identification procedure has been 
completed, the network shall abort the identification procedure and shall progress the detach procedure. 

Detach containing other causes than "switch off within the Detach type IE: 

If the network receives a DETACH REQUEST message before the ongoing identification procedure has been 
completed, the network shall complete the identification procedure and shall respond to the detach procedure 
as described in subclause 5.5.2. 

f) Collision of an identification procedure with a tracking area updating procedure 
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If the network receives a TRACKING AREA UPDATE REQUEST message before the ongoing identification 
procedure has been completed, the network shall progress both procedures. 

g) Collision of an identification procedure with a service request procedure 

If the network receives an EXTENDED SERVICE REQUEST message before the ongoing identification 
procedure has been completed, the network shall progress both procedures. 

h) Lower layers indication of non-deUvered NAS PDU due to handover 

If the IDENTITY REQUEST message could not be delivered due to an intra MME handover and the target TA 
is included in the TAI list, then upon successful completion of the intra MME handover the MME shall 

retransmit the IDENTITY REQUEST message. If a failure of the handover procedure is reported by the lower 
layer and the SI signalling connection exists, the MME shall retransmit the IDENTITY REQUEST message. 

5.4.5 EMM information procedure 

5.4.5.1 General 

The purpose of sending the EMM INFORMATION message is to allow the network to provide information to the UE. 
The message implementation is optional in the network. The UE may use the received information if the UE supports 
implementing this message. 

The EMM information procedure may be invoked by the network at any time during an established EMM context. 

5.4.5.2 EMM information procedure initiation by tine network 

The EMM information procedure consists only of the EMM INFORMATION message sent from the network to the UE 

(see example in figure 5.4.5.2.1). During an established EMM context, the network may send none, one, or more EMM 
INFORMATION messages to the UE. If more than one EMM INFORMATION message is sent, the messages need not 
have the same content. 



UE MME 

EMM INFORMATION 



Figure 5.4.5.2.1 : EMM information procedure 



5.4.5.3 EMM information procedure in the UE 

When the UE (supporting the EMM information message) receives an EMM INFORMATION message, it shall accept 
the message and optionally use the contents to update appropriate information stored within the UE. 

If the UE does not support the EMM information message the UE shall ignore the contents of the message and return an 
EMM STATUS message with cause #97 "message type non-existent or not implemented". 

5.4.5.4 Abnormal cases on the network side 

The following abnormal case can be identified: 

a) Lower layers indication of non-delivered NAS PDU due to handover 

If the EMM INFORMATION message could not be deUvered due to an intra MME handover and the target TA 
is included in the TAI list, then upon successful completion of the intra MME handover the MME shall 
retransmit the EMM INFORMATION message. If a failure of the handover procedure is reported by the lower 
layer and the SI signalling connection exists, the MME shall retransmit the EMM INFORMATION message. 
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5.5 EMM specific procedures 
5.5.1 Attach procedure 

5.5.1.1 General 

The attach procedure is used to attach to an EPC for packet services in EPS. 
The attach procedure is used for two purposes: 

- by a UE in PS mode of operation to attach for EPS services only; or 

- by a UE in CS/PS mode 1 or CS/PS mode 2 of operation to attach for both EPS and non-EPS services. 

With a successful attach procedure, a context is estabUshed for the UE in the MME, and a default bearer is established 
between the UE and the PDN GW, thus enabling always-on IP connectivity to the UE. The network may also initiate 
the activation of dedicated bearers as part of the attach procedure. 

During the attach procedure, the UE may also obtain the home agent IPv4 and IPv6 addresses. 

In a shared network, the UE shall choose one of the PLMN identities as specified in 3GPP TS 23.122 [6]. The UE shall 
construct the TAl of the cell from this chosen PLMN identity and the TAG received as part of the broadcast system 
information. The chosen PLMN identity shall be indicated to the E-UTRAN (see 3GPP TS 36.331 [22]). Whenever an 
ATTACH REJECT message with the cause #1 1 "PLMN not allowed" is received by the UE, the chosen PLMN identity 
shall be stored in the "forbidden PLMN list". Whenever an ATTACH REJECT message is received by the UE with the 
cause #13 "roaming not allowed in this tracking area", #12 "tracking area not allowed", or #15 "no suitable cells in 
tracking area", the constructed TAl shall be stored in the suitable list. 

An attach attempt counter is used to limit the number of subsequently rejected attach attempts. The attach attempt 
counter shall be incremented as specified in subclause 5.5.1.2.6. Depending on the value of the attach attempt counter, 
specific actions shall be performed. The attach attempt counter shall be reset when: 

- the UE is powered on; 

- a USIM is inserted; 

an attach or combined attach procedure is successfully completed; 

a combined attach procedure is completed for EPS services only with cause #2, #16, #17, #18 or #22; 

- an attach or combined attach procedure is rejected with cause #11, #12, #13, #14, #15 or #25; or 

- a network initiated detach procedure is completed with cause #11, #12, #13, #14, #15 or #25. 

Additionally the attach attempt counter shall be reset when the UE is in substate EMM- 
DEREGISTERED.ATTEMPTING-TO-ATTACHand: 

- a new tracking area is entered; or 

- T3402 expires. 

5.5.1 .2 Attach procedure for EPS services 

5.5.1.2.1 General 

This procedure is used by a UE to attach for EPS services only. When the UE initiates the attach procedure, the UE 
shall indicate "EPS attach" in the EPS attach type IE. 

5.5.1 .2.2 Attach procedure initiation 

In state EMM-DEREGISTERED, the UE initiates the attach procedure by sending an ATTACH REQUEST message to 
the MME, starting timer T3410 and entering state EMM-REGISTERED-INITIATED (see example in 
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figure 5.5.1.2.2.1). If timer T3402 is currently running, the UE shall stop timer T3402. If timer T3411 is currently 

running, the UE shall stop timer T3411. 

If the UE supports neither A/Gb mode nor lu mode, the UE shall handle the Old GUTI or IMSI IE in the ATTACH 
REQUEST message as follows: 

- The UE shall include in the ATTACH REQUEST message a vaUd GUTI together with the last visited registered 
TAI, if available. If there is no valid GUTI available, the UE shall include the IMSI in the ATTACH REQUEST 
message. 

If the UE supports A/Gb mode or lu mode, the UE shall handle the Old GUTI or IMSI IE as follows: 

- If the TIN indicates "P-TMSl" and the UE holds a valid P-TMSl and RAl, the UE shall map the P-TMSl and 
RAI into the Old GUTI or IMSI IE. If a P-TMSI signature is associated with the P-TMSI, the MS shall include it 
in the Old P-TMSI signature IE. Additionally, if the UE holds a vaUd GUTI, the UE shall indicate the GUTI in 
the Additional GUTI IE. 

NOTE: The mapping of the P-TMSI and the RAI to the GUTI is specified in 3GPP TS 23 .003 [2] . 

- If the TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI, the UE shall indicate the 
GUTI in the Old GUTI or IMSI IE. 

- If the TIN is deleted and 

- the UE holds a vaUd GUTI, the UE shall indicate the GUTI in the Old GUTI or IMSI IE; or 

- otherwise, if the UE holds a vahd P-TMSI and RAI, the UE shall map the P-TMSI and RAI into the Old 
GUTI or IMSI IE. If a P-TMSI signature is associated with the P-TMSI, the MS shall include it in the Old P- 
TMSl signature IE. 

- Otherwise the UE shall include the IMSI in the Old GUTI or IMSI IE. 

The UE shall send the ATTACH REQUEST message together with a PDN CONNECTIVITY REQUEST message 
contained in the ESM message container information element to request PDN connectivity. 

If UE supports A/Gb mode or lu mode or if the UE wants to indicate its UE specific DRX parameter to the network, the 
UE shall include the UE specific DRX parameter in the DRX parameter IE in the ATTACH REQUEST message. 

If a valid NAS security context exists, the UE shall integrity protect the ATTACH REQUEST message combined with 
the PDN CONNECTIVITY REQUEST message. When the UE does not have a valid NAS security context, the 
ATTACH REQUEST message combined with the PDN CONNECTIVITY REQUEST message is not integrity 
protected. 
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UE MME 

ATTACH REQUEST 

Start T34 10 





ATTACH ACCEPT 


► 











ATTACH COMPLETE 








► 



StopT3410 M Start T3450 

Stop T3450 
OR 

ATTACH REQUEST 

Start T34 1 ► 

ATTACH REJECT 

Stop T34 1 

Figure 5.5.1.2.2.1: Attach procedure and combined attacli procedure 

5.5.1 .2.3 EMM common procedure initiation 

When the network receives an ATTACH REQUEST message containing the Old GUTI or IMSI IE and the Additional 
GUTI IE with the same encoded mobile identity type "GUTI", but indicating different mobile identities, the network 
shall regard the former one as a P-TMSI and RAI and the latter one as a GUTI. 

The network may initiate EMM common procedmes, e.g. the identification, authentication and security mode control 
procedures during the attach procedure, depending on the information received in the ATTACH REQUEST message 
(e.g. IMSI, GUTI and KSI). 

5.5.1 .2.4 Attacli accepted by tine network 

If the attach request is accepted by the network, the MME shall send an ATTACH ACCEPT message to the UE and 
start timer T3450. The MME shall send the ATTACH ACCEPT message together with an ACTIVATE DEFAULT EPS 
BEARER CONTEXT REQUEST message contained in the ESM message container information element to activate the 
default bearer (see subclause 6.4.1). The network may also initiate the activation of dedicated bearers towards the UE 
by invoking the dedicated EPS bearer context activation procedure (see subclause 6.4.2). 

If the attach request is accepted by the network, the MME shall delete the stored UE radio capability information, if 
any. 

If the UE has included the UE network capability IE or the MS network capability IE or both in the ATTACH 
REQUEST message, the MME shall store all octets received from the UE, up to the maximum length defined for the 
respective information element. 

NOTE: This information is forwarded to the new MME during inter-MME handover or to the new SGSN during 
inter-system handover to A/Gb mode or lu mode. 

If the UE specific DRX parameter was included in the DRX Parameter IE in the ATTACH REQUEST message, the 
MME shall replace any stored UE specific DRX parameter with the received parameter and use it for the downlink 
transfer of signalling and user data. 

The MME shall assign and include the TAI hst the UE is registered to in the ATTACH ACCEPT message. The UE, 
upon receiving an ATTACH ACCEPT message, shall delete its old TAI Ust and store the received TAI list. 
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Upon receiving the ATTACH ACCEPT message, the UE shall stop timer T3410. 

The GUTI reallocation may be part of the attach procedure. When the ATTACH REQUEST message includes the 
IMSI, or the MME considers the GUTI provided by the UE is invahd, or the GUTI provided by the UE was assigned by 
another MME, the MME shall allocate a new GUTI to the UE. The MME shall include in the ATTACH ACCEPT 
message the new assigned GUTI together with the assigned TAI list. In this case the MME shall enter state EMM- 
COMMON-PROCEDURE-INITIATED as described in subclause 5.4.1. 

For a shared network, the TAIs included in the TAI list can contain different PLMN identities. The MME indicates the 
selected core network operator PLMN identity to the UE in the GUTI (see 3GPP TS 23.251 [8A]). 

If the ATTACH ACCEPT message contains a GUTI, the UE shall use this GUTI as the new temporary identity. The 
UE shall delete its old GUTI and store the new assigned GUTI. If no GUTI has been included by the MME in the 
ATTACH ACCEPT message, the old GUTI, if any available, shaU be kept. 

If A/Gb mode or lu mode is supported in the UE, the UE shall set its TIN to "GUTI" when receiving the ATTACH 

ACCEPT message. 

The MME may also include a list of equivalent PLMNs in the ATTACH ACCEPT message. Each entry in the list 
contains a PLMN code (MCC+MNC). The UE shall store the list as provided by the network, after having removed 
from the list any PLMN code that is already in the list of forbidden PLMNs. In addition, the UE shall add to the stored 
list the PLMN code of the registered PLMN that sent the hst. The UE shall replace the stored list on each receipt of the 
ATTACH ACCEPT message. If the ATTACH ACCEPT message does not contain a list, then the UE shall delete the 
stored Ust. 

When the UE receives the ATTACH ACCEPT message combined with the ACTIVATE DEFAULT EPS BEARER 
CONTEXT REQUEST message, it shall forward the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST 
message to the ESM sublayer. Upon receipt of an indication from the ESM sublayer that the default EPS bearer context 
has been activated, the UE shall send an ATTACH COMPLETE message together with an ACTIVATE DEFAULT 
EPS BEARER CONTEXT ACCEPT message contained in the ESM message container information element to the 
network. 

Additionally, the UE shall reset the attach attempt counter and tracking area updating attempt counter, enter state EMM- 
REGISTERED and set the EPS update status to EUl UPDATED. 

When the UE receives any ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST messages during the 
attach procedure, the UE shall forward the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST 
message(s) to the ESM sublayer. The UE shall send a response to the ACTIVATE DEDICATED EPS BEARER 
CONTEXT REQUEST message(s) after successful completion of the attach procedure. 

If the attach procedure was initiated in S 101 mode, the lower layers are informed about the successful completion of the 
procedure. 

Upon receiving an ATTACH COMPLETE message, the MME shall stop timer T3450, enter state EMM-REGISTERED 
and consider the GUTI sent in the ATTACH ACCEPT message as valid. 

5.5.1 .2.5 Attach not accepted by the network 

If the attach request cannot be accepted by the network, the MME shall send an ATTACH REJECT message to the UE 
including an appropriate EMM cause value. If the attach procedure fails due to a default EPS bearer setup failure, an 
ESM procedure failure, or operator determined barring is applied on default EPS bearer context activation during attach 
procedure, the MME shall combine the ATTACH REJECT message with a PDN CONNECTIVITY REJECT message 
contained in the ESM message container information element. In this case the EMM cause value in the ATTACH 
REJECT message shall be set to #19 "ESM failure". 

Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410 and take the following actions 
depending on the EMM cause value received. 

#3 (Illegal UE); or 

#6 (Illegal ME); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall consider the 
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USIM as invalid for EPS services and non-EPS services until switching off or the UICC containing the USIM is 
removed. Additionally, the UE shall delete the list of equivalent PLMNs and enter state EMM- 
DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the MM parameters update 
status, TMSI, LAI and ciphering key sequence number, and the GMM parameters GMM state, GPRS update 
status, P-TMSI, P-TMSI signatiu'e, RAI and GPRS ciphering key sequence number as specified in 
3GPP TS 24.008 [13] for the case when the normal attach procedure is rejected with the GMM cause with the 
same value. 

NOTE: The possibility to configure a UE so that the radio transceiver for a specific RAT is not active, although it 
is implemented in the UE, is out of scope of the present specification. 

#7 (EPS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall consider the 
USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
Additionally, the UE shall delete the list of equivalent PLMNs and enter state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as 
specified in 3GPP TS 24.008 [13] for the case when the normal attach procedure is rejected with the GMM cause 
with the same value. 

#8 (EPS services and non-EPS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall consider the 
USIM as invalid for EPS services and non-EPS services until switching off or the UICC containing the USIM is 
removed. Additionally, the UE shall delete the list of equivalent PLMNs and enter state EMM- 
DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the MM parameters update 
status, TMSI, LAI and ciphering key sequence number, and the GMM parameters GMM state, GPRS update 
status, P-TMSl, P-TMSl signature, RAI and GPRS ciphering key sequence number as specified in 
3GPP TS 24.008 [13] for the case when the normal attach procedure is rejected with the GMM cause with the 
same value. 

#1 1 (PLMN not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. Additionally, the UE shall 
delete the list of equivalent PLMNs and reset the attach attempt counter, and enter state EMM- 
DEREGISTERED.PLMN-SEARCH. 

In SI mode, the UE shall store the PLMN identity in the "forbidden PLMN list" and enter state EMM- 
DEREGISTERED.PLMN-SEARCH. The UE shall perform a PLMN selection according to 
3GPPTS 23.122 [6]. 

In SlOl mode, the UE shall store the PLMN identity provided with the indication from the lower layers to 
prepare for an SlOl mode to SI mode handover in the list of "forbidden PLMNs for attach in SlOl mode" and 
enter the state EMM-DEREGISTERED .NO-CELL- AVAILABLE. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the MM parameters update 
status, TMSI, LAI, ciphering key sequence number and location update attempt counter, and the GMM 
parameters GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence 
number and GPRS attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the normal 
attach procedure is rejected with the GMM cause with the same value and no RR connection exists. 

#12 (Tracking area not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. Additionally, the UE shall 
reset the attach attempt counter. 
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In SI mode, the UE shall store the current TAI in the list of "forbidden tracking areas for regional provision of 
service" and enter the state EMM-DEREGISTERED.LIMITED-SERVICE. 

In S 101 mode, the UE shall store the PLMN identity provided with the indication from the lower layers to 
prepare for an SlOl mode to SI mode handover in the list of "forbidden PLMNs for attach in SlOl mode" and 
enter the state EMM-DEREGISTERED .NO-CELL-AVAILABLE. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence number and GPRS 
attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the normal attach procedure is 
rejected with the GMM cause with the same value. 

#13 (Roaming not allowed in this tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall delete the list of 
equivalent PLMNs and reset the attach attempt counter. 

In SI mode, the UE shall store the current TAI in the list of "forbidden tracking areas for roaming". 
Additionally, the UE shall enter the state EMM-DEREGISTERED.LIMITED-SERVICE or optionally EMM- 
DEREGISTERED.PLMN-SEARCH. The UE shall perform a PLMN selection according to 
3GPPTS 23.122 [6J. 

In S 101 mode, the UE shall store the PLMN identity provided with the indication from the lower layers to 
prepare for an SlOl mode to SI mode handover in the list of "forbidden PLMNs for attach in SlOl mode" and 
enter the state EMM-DEREGISTERED .NO-CELL-AVAILABLE. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence number and GPRS 
attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the normal attach procedure is 
rejected with the GMM cause with the same value. 

#14 (EPS services not allowed in this PLMN); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. 

In SI mode, the UE shall store the PLMN identity in the "forbidden PLMNs for GPRS service" list. 
Additionally, the UE shall enter state EMM-DEREGISTERED .PLMN-SEARCH. The UE shall perform a 
PLMN selection according to 3GPP TS 23.122 [6]. 

In SlOl mode, the UE shall store the PLMN identity provided with the indication from the lower layers to 
prepare for an SlOl mode to SI mode handover in the list of "forbidden PLMNs for attach in SlOl mode" and 
enter the state EMM-DEREGISTERED .NO-CELL-AVAILABLE. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence number and GPRS 
attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the normal attach procedure is 
rejected with the GMM cause with the same value. 

#15 (No suitable cells in tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. Additionally, the UE shall 
reset the attach attempt counter. 

In SI mode, the UE shall store the current TAI in the list of "forbidden tracking areas for roaming" and enter the 
state EMM-DEREGISTERED.LIMITED-SERVICE. The UE shall search for a suitable cell in another tracking 
area or in another location area in the same PLMN according to 3GPP TS 36.304 [21]. 

In SlOl mode, the UE shall store the PLMN identity provided with the indication from the lower layers to 
prepare for an SlOl mode to SI mode handover in the list of "forbidden PLMNs for attach in SlOl mode" and 
enter the state EMM-DEREGISTERED .NO-CELL-AVAILABLE. 
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If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence number and GPRS 
attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the normal attach procedure is 
rejected with the GMM cause with the same value. 

#25 (Not authorized for this CSG); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). Additionally, the UE shall reset the attach attempt counter and shall enter the state EMM- 
DEREGISTERED.LIMITED-SERVICE. 

The UE shall remove the CSG ID of the cell where the UE has sent the ATTACH REQUEST message from the 
Allowed CSG Ust. 

The UE shall search for a suitable cell in the same PLMN according to 3GPP TS 36.304 [21]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status and GPRS attach attempt counter as specified in 3GPP TS 24.008 [13] for the case 
when the normal attach procedure is rejected with the GMM cause with the same value. 

Other values are considered as abnormal cases. 
5.5.1 .2.6 Abnormal cases in the UE 

The following abnormal cases can be identified: 

a) Access barred because of access class barring or NAS signalhng connection establishment rejected by the 
network 

If access is barred for "signalling" (see 3GPP TS 36.331 [22]), the attach procedure shall not be started. The UE 
stays in the current serving cell and applies the normal cell reselection process. The attach procedure is started as 
soon as possible, i.e. when access for "signalling" is granted on the current cell or when the UE moves to a cell 
where access for "signalling" is granted. 

b) Lower layer failure or release of the NAS signalling connection before the ATTACH ACCEPT or ATTACH 
REJECT message is received 

The attach procedure shall be aborted, and the UE shall proceed as described below. 

c) T34 10 timeout 

The UE shall abort the attach procedure and proceed as described below. The NAS signalling connection shall 
be released locally. 

d) ATTACH REJECT, other EMM cause values than those treated in subclause 5.5.1.2.5 

Upon reception of the EMM cause #19, "ESM failure", the UE may set the attach attempt counter to 5. Upon 
reception of the EMM causes #95, #96, #97, #99 and #111 the UE should set the attach attempt counter to 5. 

The UE shall proceed as described below. 

e) Change of cell into a new tracking area 

If a cell change into a new tracking area occurs before the attach procedure is completed, the attach procedure 
shall be aborted and re-initiated immediately. If a tracking area border is crossed when the ATTACH ACCEPT 
message has been received but before an ATTACH COMPLETE message is sent, the attach procedure shall be 
re-initiated. If a GUTI was allocated during the attach procedure, this GUTI shall be used in the attach 
procedure. 

f) Mobile originated detach required 

The attach procedure shall be aborted, and the UE initiated detach procedure shall be performed. 

g) Detach procedure collision 
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If the UE receives a DETACH REQUEST message from the network in state EMM-REGISTERED-INITIATED 
and the detach type indicates "re-attach not required", the detach procedure shall be progressed and the attach 
procedure shall be aborted. Otherwise the attach procedure shall be progressed and the DETACH REQUEST 
message shall be ignored. 

h) Transmission failure of ATTACH REQUEST message indication from lower layers 
The UE shall restart the attach procedure. 

i) Transmission failure of ATTACH COMPLETE message indication from lower layers 
If the current TAI is not in the TAI list, the UE shall restart the attach procedure. 

If the current TAI is still in the TAI list, it is up to the UE implementation how to re-run the ongoing procedure. 
The EMM sublayer notifies the ESM sublayer that the ESM message in the ESM message container IE of the 
ATTACH COMPLETE has failed to be transnoitted. 

j) If the ACTIVATE DEFAULT BEARER CONTEXT REQUEST message combined with the ATTACH 

ACCEPT is not accepted by the UE due to failure in the UE ESM sublayer, then the UE shall initiate the detach 
procedure by sending a DETACH REQUEST message to the network. Further UE behaviour is implementation 
specific. 

k) Indication from the lower layers that an S 101 mode to SI mode handover has been cancelled (SlOl mode only) 
The UE shall abort the attach procedure and enter state EMM-DEREGISTERED.NO-CELL-AVAILABLE. 
For the cases b, c, and d the UE shall proceed as follows: 

- Timer T3410 shall be stopped if still rurming. The attach attempt counter shall be incremented, unless it was 
already set to 5. 

If the attach attempt counter is less than 5: 

- timer T341 1 is started and the state is changed to EMM-DEREGISTERED.ATTEMPTING-TO- ATTACH. 
When timer T341 1 expires the attach procedure shall be restarted. 

If the attach attempt counter is equal to 5: 

- the UE shall delete any GUTI, TAI list, last visited registered TAI, list of equivalent PLMNs and KSI, shall set 
the update status to EU2 NOT UPDATED, and shall start timer T3402. The state is changed to EMM- 
DEREGISTERED.ATTEMPTING-TO-ATTACH or optionally to EMM-DEREGISTERED.PLMN-SEARCH in 
order to perform a PLMN selection according to 3GPP TS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as 
specified in 3GPP TS 24.008 [13] for the abnormal case when a normal attach procedure fails and the attach 
attempt counter is equal to 5. 

5.5.1 .2.7 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) Lower layer failure 

If a lower layer failure occurs before the message ATTACH COMPLETE has been received from the UE, the 
network shall locally abort the attach procedure, enter state EMM-DEREGISTERED and shall not resend the 
message ATTACH ACCEPT. If a new GUTI was assigned to the UE in the attach procedure, the MME shall 
consider both the old and new GUTI as valid until the old GUTI can be considered as invalid by the network (see 
subclause 5.4.1.6). During this period the network may: 

use the identification procedure followed by a GUTI reallocation procedure if the old GUTI is used by the 
UE in a subsequent message. 

b) Protocol error 
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If the ATTACH REQUEST message is received with a protocol error, the network shall return an ATTACH 
REJECT message with one of the following EMM cause values: 

#96: invalid mandatory information; 

#99: information element non-existent or not implemented; 
#100: conditional IE error; or 
#111: protocol error, unspecified. 

c) T3450 time-out 

On the first expiry of the timer, the network shall retransmit the ATTACH ACCEPT message and shall reset and 
restart timer T3450. 

This retransmission is repeated four times, i.e. on the fifth expiry of timer T3450, the attach procedure shall be 
aborted. If a new GUTI was allocated in the ATTACH ACCEPT message, the network shall consider both the 
old and new GUTI as valid until the old GUTI can be considered as invalid by the network (see 
subclause 5.4.1.6). During this period the network acts as specified for case a above. 

d) ATTACH REQUEST received after the ATTACH ACCEPT message has been sent and before the ATTACH 
COMPLETE message is received 

If one or more of the information elements in the ATTACH REQUEST message differ from the ones 
received within the previous ATTACH REQUEST message, the previously initiated attach procedure shall 
be aborted if the ATTACH COMPLETE message has not been received and the new attach procedure shall 
be progressed; or 

if the information elements do not differ, then the ATTACH ACCEPT message shall be resent and the timer 
T3450 shall be restarted if an ATTACH COMPLETE message is expected. In that case, the retransmission 
counter related to T3450 is not incremented. 

e) More than one ATTACH REQUEST received and no ATTACH ACCEPT or ATTACH REJECT message has 
been sent 

- If one or more of the information elements in the ATTACH REQUEST message differs from the ones 
received within the previous ATTACH REQUEST message, the previously initiated attach procedure shall 

be aborted and the new attach procedure shall be executed; 

- if the information elements do not differ, then the network shall continue with the previous attach procedure 
and shall ignore the second ATTACH REQUEST message. 

f) ATTACH REQUEST received in state EMM-REGISTERED 

If an ATTACH REQUEST message is received in state EMM-REGISTERED the network may initiate the 
EMM common procedures; if it turned out that the ATTACH REQUEST message was sent by a UE that has 
already been attached, the EMM context, EPS bearer contexts, if any, are deleted and the new ATTACH 

REQUEST is progressed. 

g) TRACKING AREA UPDATE REQUEST message received before ATTACH COMPLETE message. 

Timer T3450 shall be stopped. The allocated GUTI shall be considered as valid and the tracking area updating 
procedure shall be executed as described in subclause 5.5.3. 

5.5.1 .3 Combined attach procedure for EPS services and non-EPS services 
(S1 mode only) 

5.5.1.3.1 General 

The combined attach procedure is used by a UE in CS/PS mode 1 or CS/PS mode 2 of operation to attach for both EPS 
and non-EPS services. 

The combined attach procedure is also used by a UE in CS/PS mode 1 or CS/PS mode 2 of operation to attach for EPS 
services if it is already IMSI attached for non-EPS services. 
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When the UE initiates a combined attach procedure, the UE shall indicate "combined EPS/IMSI attach" in the EPS 

attach type IE. 

The combined attach procedure follows the attach procedure for EPS described in subclause 5.5.1.2. 

5.5.1 .3.2 Combined attach procedure initiation 

If the UE is in EMM state EMM-DEREGISTERED, the UE initiates the combined attach procedure by sending an 
ATTACH REQUEST message to the network, starting timer T3410 and entering state EMM-REGISTERED- 
INITIATED (see example in figure 5.5.1.2.2.1). 

The UE shall include the TMSI status IE if no valid TMSI is available. Furthermore, if the UE has stored a valid 
location area identification, the UE shall include it in the Old location area identification IE in the ATTACH REQUEST 
message. 

5.5.1 .3.3 EMM common procedure initiation 

The network may initiate EMM common procedures, e.g. the identification, authentication and security mode control 
procedures, depending on the received information such as IMSI, GUTI and KSI. 

5.5.1 .3.4 Combined attacli accepted by tine network 

5.5.1.3.4.1 General 

Depending on the value of the EPS attach result IE received in the ATTACH ACCEPT message, two different cases 
can be distinguished: 

1) The EPS attach result IE value indicates "combined EPS/IMSI attach": attach for EPS and non-EPS services 
have been successful. 

2) The EPS attach result IE value indicates "EPS only": attach for EPS services has been successful but attach for 
non-EPS services has failed. 

5.5.1 .3.4.2 Combined attach successful 

The description for attach for EPS services as specified in subclause 5.5.1.2.4 shall be followed. In addition, the 
following description for attach for non-EPS services applies. 

The TMSI reallocation may be part of the combined attach procedure. The TMSI allocated is then included in the 
ATTACH ACCEPT message, together with the location area identification (LAI). In this case the MME shall start timer 
T3450 and enter state EMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.4.1. 

The UE, receiving an ATTACH ACCEPT message, stores the received location area identification, stops timer T3410, 
resets the location update attempt counter and sets the update status to Ul UPDATED. If the message contains an IMSI, 
the UE is not allocated any TMSI, and shall delete any TMSI accordingly. If the message contains a TMSI, the UE shall 
use this TMSI as the new temporary identity. The UE shall delete its old TMSI and shall store the new TMSI. If neither 
a TMSI nor an IMSI has been included by the network in the ATTACH ACCEPT message, the old TMSI, if any 
available, shall be kept. 

If the LAI contained in the ATTACH ACCEPT message is a member of the list of "forbidden location areas for 
regional provision of service" or the list of "forbidden location areas for roaming" then such entry shall be deleted. 

The UE, when receiving the ATTACH ACCEPT message combined with the ACTIVATE DEFAULT EPS BEARER 
CONTEXT REQUEST message, shall send an ATTACH COMPLETE message combined with an ACTIVATE 
DEFAULT EPS BEARER CONTEXT ACCEPT message to the network after which it shall enter state EMM- 
REGISTERED and MM state MM-IDLE and set the EPS update status to EUl UPDATED. 

Upon receiving an ATTACH COMPLETE message, the MME shall stop timer T3450, enter state EMM-REGISTERED 
and consider the new TMSI sent in the ATTACH ACCEPT message as valid. 
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5.5.1 .3.4.3 Combined attach successful for EPS services only 

Apart from the actions on the tracking area updating attempt counter, the description for attach for EPS services as 
specified in subclause 5.5.1.2.4 shall be followed. In addition, the following description for attach for non-EPS services 
applies. 

The UE receiving the ATTACH ACCEPT message takes one of the following actions depending on the EMM cause 
value: 

#2 (IMSI unknown in HSS) 

The UE shall stop T3410 if still running and shall reset the tracking area updating attempt counter. The UE 
shall set the update status to U3 ROAMING NOT ALLOWED and shall delete any TMSI, LAI and ciphering 
key sequence number. The UE shall enter state EMM-REGISTERED.NORMAL-SERVICE. The new MM 
state is MM IDLE. The USIM shall be considered as invalid for non-EPS services until switching off or the 
UICC containing the USIM is removed. 

#16 (MSC temporarily not reachable); 

#17 (Network failure); or 

#22 (Congestion) 

The UE shall stop timer T3410 if still running. The tracking area updating attempt counter shall be 
incremented, unless it was already set to 5. 

If the tracking area updating attempt counter is less than 5: 

- the UE shall start timer T341 1, shall set the EPS update status to EUl UPDATED and shall enter state 
EMM-REGISTERED. ATTEMPTING-TO-UPDATE-MM. When timer T341 1 expires the combined 
tracking area updating procedure indicating "combined TA/LA updating with IMSI attach" is triggered. 

If the tracking area updating attempt counter is equal to 5: 

- the UE shall start timer T3402, shall set the EPS update status to EUl UPDATED and shall enter state 
EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM. When timer T3402 expires the combined 
tracking area updating procedure indicating "combined TA/LA updating with IMSI attach" is triggered; 

- a UE operating in CS/PS mode 1 of operation shall select GERAN or UTRAN radio access technology 
and proceed with appropriate MM or GMM specific procedures. 

NOTE 1: It is up to the UE implementation when to enable E-UTRAN radio access technology selection. 

#18 (CS domain not available) 

The UE shall stop timer T3410 if still running, shall reset the tracking area updating attempt counter, shall set 
the EPS update status to EUl UPDATED and shall enter state EMM-REGISTERED.NORMAL-SERVICE. 

The UE shall set the update status to U2 NOT UPDATED. 

A UE in CS/PS mode 1 of operation shall preferably select GERAN or UTRAN radio access technology 
rather than E-UTRAN for the selected PLMN or equivalent PLMN. 

NOTE 2: Some interaction is required with the access stratum layer(s) to give the lowest priority (as defined in 
3GPP TS 25.304 [15A], 3GPP TS 36.304 [21] and 3GPP TS 45.008 [23A]) to E-UTRAN. The NAS 
indicated priority takes precedence over any priority information already stored in the access stratum 
layer(s) and is valid until PLMN selection (as defined in 3GPP TS 23.122 [6]) is performed. 

The UE shall not attempt combined attach or combined tracking area update procedure with current PLMN 
until switching off the UE or the UICC containing the USIM is removed. 

Other EMM cause values and the case that no EMM cause IE was received are considered as abnormal cases. The 
combined attach procedure shall be considered as failed for EPS and non-EPS services. The behaviour of the UE in 
those cases is specified in subclause 5.5.1.3.6. 
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5.5.1 .3.5 Combined attach not accepted by the network 

If the attach request can neither be accepted by the network for EPS nor for non-EPS services, the MME shall send an 
ATTACH REJECT message to the UE including an appropriate EMM cause value. If the attach procedure fails due to a 
default EPS bearer setup failure or an ESM procedure failure, the MME shall combine the ATTACH REJECT message 
with a PDN CONNECTIVITY REJECT message. In this case the EMM cause value in the ATTACH REJECT message 

shall be set to #19, "ESM failure". 

Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410, enter MM state MM IDLE, and take 
the following actions depending on the EMM cause value received. 

#3 (Illegal UE); 

#6 (Illegal ME); or 

#8 (EPS services and non-EPS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclauses. 1.3. 3) and shall delete any GUTI, last visited registered TAI and KSI. 

The UE shall consider the USIM as invalid for EPS and non-EPS services until switching off or the UICC 
containing the USIM is removed. Additionally, the UE shall delete the list of equivalent PLMNs and shall enter 
the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the MM parameters update 
status, TMSI, LAI and ciphering key sequence number, and the GMM parameters GMM state, GPRS update 
status, P-TMSI, P-TMSl signature, RAl and GPRS ciphering key sequence number as specified in 
3GPP TS 24.008 [13] for the case when the combined attach procedure is rejected with the GMM cause with the 
same value. 

#7 (EPS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall consider the 
USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
Additionally, the UE shall delete the list of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

A UE which is not yet IMSI attached for non-EPS services shall select GERAN or UTRAN radio access 
technology and perform an IMSI attach for non-EPS services, using the MM IMSI attach procedure as described 
in 3GPP TS 24.008 [13]. The UE shall not reselect E-UTRAN radio access technology until switching off or the 
UICC containing the USIM is removed. 

A UE which is already IMSI attached for non-EPS services is still IMSI attached for non-EPS services in the 
network. The UE shall select GERAN or UTRAN radio access technology and shall proceed with the 
appropriate MM specific procedure according to the MM service state. The UE shall not reselect E-UTRAN 
radio access technology until switching off or the UICC containing the USIM is removed. 

NOTE: Some interaction is required with the access stratum to disable E-UTRAN cell reselection. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as 
specified in 3GPP TS 24.008 [13] for the case when the combined attach procedure is rejected with the GMM 
cause with the same value. 

#11 (PLMN not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, and KSI, and reset the attach attempt 
counter. The UE shall delete the Ust of equivalent PLMNs and enter the state EMM-DEREGISTERED.PLMN- 
SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMN list". 

The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6]. 
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If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the MM parameters update 
status, TMSI, LAI, ciphering key sequence number and location update attempt counter, and the GMM 
parameters GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence 
number and GPRS attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined 
attach procedure is rejected with the GMM cause with the same value and no RR connection exists. 

#12 (Tracking area not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall reset the attach 
attempt counter and enter the state EMM-DEREGISTERED.LIMITED-SERVICE. 

The UE shall store the current TAI in the list of "forbidden tracking areas for regional provision of service". 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the MM parameters update 
status, TMSI, LAI, ciphering key sequence number and location update attempt counter, and the GMM 
parameters GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence 
number and GPRS attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined 
attach procedure is rejected with the GMM cause with the same value. 

#13 (Roaming not allowed in this tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall delete the list of 
equivalent PLMNs and reset the attach attempt counter. Additionally the UE enter the state EMM- 
DEREGISTERED.LIMITED-SERVICE or optionally EMM-DEREGISTERED.PLMN-SEARCH. 

The UE shall store the current TAI in the list of "forbidden tracking areas for roaming". 

The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the MM parameters update 
status, TMSI, LAI, ciphering key sequence number and location update attempt counter, and the GMM 
parameters GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence 
number and GPRS attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined 
attach procedure is rejected with the GMM cause with the same value. 

#14 (EPS services not allowed in this PLMN); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. Additionally the UE shall 
reset the attach attempt counter and enter the state EMM-DEREGISTERED.PLMN-SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMNs for GPRS service" list. 

A UE operating in CS/PS mode 1 which is not yet IMSI attached for non-EPS services may select GERAN or 
UTRAN radio access technology and perform an IMSl attach for non-EPS services, using the MM IMSI attach 
procedure as described in 3GPP TS 24.008 [13]. In this case the UE shall not reselect E-UTRAN radio access 
technology for the duration the UE is on the PLMN or an equivalent PLMN. 

A UE operating in CS/PS mode 1 which is already IMSI attached for non-EPS services in the network is still 
IMSI attached for non-EPS services in the network. The UE may select GERAN or UTRAN radio access 
technology and proceed with the appropriate MM specific procedure according to the MM service state. In this 
case the UE shall not reselect E-UTRAN radio access technology for the duration the UE is on the PLMN or an 
equivalent PLMN. 

A UE in CS/PS mode 1 of operation may perform a PLMN selection according to 3GPP TS 23.122 [6]. 

A UE operating in CS/PS mode 2 which is already IMSI attached for non-EPS services in the network is still 
IMSI attached for non-EPS services in the network. 

A UE operating in CS/PS mode 2 of operation shall perform a PLMN selection according to 
3GPPTS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence number and GPRS 
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attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined attach procedure is 

rejected with the GMM cause with the same value. 

#15 (No suitable cells in tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSL Additionally the UE shall 
reset the attach attempt counter and enter the state EMM-DEREGISTERED.LIMITED-SERVICE. 

The UE shall store the current TAI in the list of "forbidden tracking areas for roaming". 

The UE shall search for a suitable cell in another tracking area or in another location area in the same PLMN 
according to 3GPP TS 36.304 [21]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the MM parameters update 
status, TMSI, LAI, ciphering key sequence number and location update attempt counter, and the GMM 
parameters GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAl, GPRS ciphering key sequence 
number and GPRS attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined 
attach procedure is rejected with the GMM cause with the same value. 

#25 (Not authorized for this CSG); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). Additionally, the UE shall reset the attach attempt counter and shall enter the state EMM- 
DEREGISTERED.LIMITED-SERVICE. 

The UE shall remove the CSG ID of the cell where the UE has sent the ATTACH REQUEST message fi-om the 
Allowed CSG Ust. 

The UE shall search for a suitable cell in the same PLMN according to 3GPP TS 36.304 [21]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the MM parameters update 
status and location update attempt counter, and GMM parameters GMM state, GPRS update status and GPRS 
attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined attach procedure is 
rejected with the GMM cause with the same value. 

Other values are considered as abnormal cases. The behaviour of the UE in those cases is specified in 
subclause 5.5.1.3.6. 

5.5.1 .3.6 Abnormal cases in the UE 

The UE shall proceed as follows: 

if the combined attach was successful for EPS services only and the ATTACH ACCEPT message contained an 
EMM cause value not treated in subclause 5.5.1.3.4.3 or the EMM cause IE is not included in the message, the 
UE shall follow the procedure specified in subclause 5.5.1.2.6 item d, with the following modification; 

- otherwise, the abnormal cases specified in subclause 5.5.1.2.6 apply with the following modification. 

If the attach attempt counter is incremented according to subclause 5.5.1.2.6 the next actions depend on the value of the 
attach attempt counter: 

if the update status is Ul UPDATED and the attach attempt counter is less than 5, then the UE shall keep the 
update status to Ul UPDATED, the new MM state is MM IDLE substate NORMAL SERVICE; 

if the attach attempt counter is less than 5 and, additionally, the update status is different from Ul UPDATED, 
then the UE shall delete any LAI, TMSI, ciphering key sequence number and list of equivalent PLMNs and set 
the update status to U2 NOT UPDATED. The MM state remains MM LOCATION UPDATING PENDING; or 

- if the attach attempt counter is equal to 5, then the UE shall delete any LAI, TMSI, ciphering key sequence 
number and list of equivalent PLMNs and set the update status to U2 NOT UPDATED. A UE operating in 
CS/PS mode 1 of operation shall select GERAN or UTRAN radio access technology and proceed with 
appropriate MM or GMM specific procedures. 

NOTE: It is up to the UE implementation when to enable E-UTRAN radio access technology selection. 
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5.5.1 .3.7 Abnormal cases on the network side 

The abnormal cases specified in subclause 5.5.1.2.7 apply with the exceptions for cases a and c in which in addition to 
the GUTI the old TMSI shall be considered occupied until the new TMSI is used by the UE in a subsequent message. 

5.5.2 Detach procedure 

5.5.2.1 General 

The detach procedure is used: 

- by the UE to detach for EPS services only; 

by the UE to disconnect from the last PDN it is connected to; 

- by the UE in CS/PS mode 1 or CS/PS mode 2 of operation to detach for both EPS services and non-EPS services 
or for non-EPS services only via a combined detach procedure; and 

- by the network to inform the UE that it does not have access to the EPS any longer. 

NOTE: After a successful completion of an inter-system change of the UE from SI mode to non-3GPP access, if 
the non-3GPP network provides PDN connectivity to the same EPC, the MME performs a local detach of 
theUE. 

The detach procedure shall be invoked by the UE if the UE is switched off, the USIM card is removed from the UE or 
the EPS capability or CS Fallback capability of the UE is disabled. 

If the detach procedure for EPS services is performed, the EPS bearer context(s) for this particular UE are deactivated 
locally without peer-to-peer signalling between the UE and the MME. 

Upon successful completion of the detach procedure, the UE and the MME shall delete the EPS mapped security 
context if any. 

If the UE supports A/Gb mode or lu mode, the UE shall store the TIN in the non- volatile memory in the ME, as 
described in annex C, for a subsequent attach procedure. 

5.5.2.2 UE initiated detach procedure 
5.5.2.2.1 UE initiated detach procedure initiation 

The detach procedure is initiated by the UE by sending a DETACH REQUEST message (see example in 
figure 5.5.2.2.1.1). The Detach type IE included in the message indicates whether detach is due to a "switch off or not. 
The Detach type IE also indicates whether the detach is for EPS services only, for non-EPS services only, or for both. If 
the UE has a mapped EPS security context as the current EPS security context, the UE shall set the type of security 
context flag to "mapped security context". Otherwise, the UE shall set the type of security context flag to "native 
security context". 

If the detach is not due to switch off and the UE is in the state EMM-REGISTERED or EMM-REGISTERED- 
INITIATED, timer T3421 shall be started in the UE after the DETACH REQUEST message has been sent. The UE 
shall store the current EPS security context. If the detach type indicates that the detach is for non-EPS services only the 
UE shall enter the state EMM-REGISTERED.IMSI-DETACH-INITIATED, otherwise the UE shall enter the state 
EMM-DEREGISTERED-INITIATED. If the detach type indicates that the detach is for non-EPS services or both EPS 
and non-EPS services, the UE shall enter the state MM IMSI DETACH PENDING. 

If the UE is to be switched off, the UE shall try for a period of 5 seconds to send the DETACH REQUEST message. 
During this period, the UE may be switched off as soon as the DETACH REQUEST message has been sent. After 
transmission of the message, the UE shall delete the current EPS security context if it is different from the native 
security context. 
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UE 



MME 



Start T3421 



DETACH REQUEST 



Stop T3421 



DETACH ACCEPT 



or UE at switch off: 



DETACH REQUEST 



Figure 5.5.2.2.1.1: UE initiated detach procedure 



5.5.2.2.2 UE initiated detacli procedure completion for EPS services only 

When the DETACH REQUEST message is received by the network, the network shall send a DETACH ACCEPT 
message to the UE and store the current EPS security context, if the Detach type IE does not indicate "switch off". 
Otherwise, the procedure is completed when the network receives the DETACH REQUEST message. On reception of a 
DETACH REQUEST message indicating "switch off, the MME shall delete the current EPS security context if 
different from the EPS native security context. 

The network and the UE shall deactivate the EPS bearer context(s) for this UE locally without peer-to-peer signalling 
between the UE and the MME. 

The UE, when receiving the DETACH ACCEPT message, shall stop timer T3421. 

The UE is marked as inactive in the network for EPS services. State EMM-DEREGISTERED is entered in the network. 

The UE in PS mode of operation shall enter the EMM-DEREGISTERED state. 

The UE in CS/PS mode I or CS/PS mode 2 of operation shall enter the EMM-NULL state. 



5.5.2.2.3 UE initiated combined detach procedure completion 

When the DETACH REQUEST message is received by the network, a DETACH ACCEPT message shall be sent to the 
UE, if the Detach type IE value indicates that the detach request has not been sent due to switching off. Depending on 
the value of the Detach type IE the following applies: 

- combined EPS/IMSI detach: 



The UE is marked as inactive in the network for EPS and for non-EPS services. The states EMM- 
DEREGISTERED and MM-NULL are entered in both the UE and the network. 



- IMSI detach: 



The UE is marked as inactive in the network for non-EPS services. The states MM-NULL and EMM- 
REGISTERED are entered in both the UE and the network. 



5.5.2.2.4 Abnormal cases in the UE 

The following abnormal cases can be identified: 

a) Access barred because of access class barring or NAS signalUng connection establishment rejected by the 
network 
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If access is barred for "signalling" (see 3GPP TS 36.331 [22]), the detach signalling procedure shall not be 
started. The UE stays in the current serving cell and applies the normal cell reselection process. The detach 
signalling procedure is started as soon as possible and if still necessary, i.e. when access for "signalling" is 
granted on the current cell or when the UE moves to a cell where access for "signalhng" is granted. The UE may 
perform a local detach either immediately or after an implementation dependent time. 

b) Lower layer failure or release of the NAS signalling connection before reception of DETACH ACCEPT message 
The detach procedure shall be aborted, and the UE shall enter state: 

- EMM-REGISTERED.NORMAL-SERVICE and MM-NULL if "IMSI detach" was requested; 

- EMM-DEREGISTERED if "EPS detach" was requested; 

- EMM-DEREGISTERED and MM-NULL if "combined EPS/IMSI detach" was requested. 

c) T3421 timeout 

On the first four expiries of the timer, the UE shall retransmit the DETACH REQUEST message and shall reset 
and restart timer T3421. On the fifth expiry of timer T3421, the detach procedure shall be aborted and the UE 
shall change to state: 

- EMM-REGISTERED.NORMAL-SERVICE and MM-NULL if "IMSI detach" was requested; 

- EMM-DEREGISTERED if "EPS detach" was requested; 

- EMM-DEREGISTERED and MM-NULL if "combined EPS/IMSI detach" was requested. 

d) Detach procedure collision 

If the UE receives a DETACH REQUEST message before the UE initiated detach procedure has been 
completed, it shall treat the message as specified in subclause 5.5.2.3.2 and send a DETACH ACCEPT message 
to the network. 

e) Detach and EMM common procedure collision 
Detach containing cause "switch off": 

- If the UE receives a message used in an EMM common procedure before the detach procedure has been 
completed, this message shall be ignored and the detach procedure shall continue 

Detach containing other causes than "switch off: 

- If the UE receives a GUTl REALLOCATION COMMAND, an EMM STATUS or an EMM 
INFORMATION message before the detach procedure is completed, this message shall be ignored and the 
detach procedure shall continue. 

- If the UE receives an AUTHENTICATION REQUEST, SECURITY MODE COMMAND or IDENTITY 
REQUEST message before the detach procedure has been completed, the UE shall respond to it as described 
in subclause 5.4.2, 5.4.3 and 5.4.4 respectively and the detach procedure shall continue. 

f) Change of cell into a new tracking area 

If a cell change into a new tracking area that is not in the stored TAl list occurs before the UE initiated detach 
procedure is completed, the detach procedure shall be aborted and re-initiated after successfully performing a 
tracking area updating procedure. If the detach procedure was initiated due to removal of the USIM, the UE shall 
abort the detach procedure and enter the state EMM-DEREGISTERED. 

g) Transmission failure of DETACH REQUEST message indication with TAI change from lower layers 

If the current TAl is not in the TAI list, the detach procedure shall be aborted and re-initiated after successfully 
performing a tracking area updating procedure. 

If the current TAI is still part of the TAI list, the UE shall restart the detach procedure. 

h) Transmission failure of DETACH REQUEST message indication without TAI change from lower layers 
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The UE shall restart the detach procedure. 
5.5.2.2.5 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) CSG ID of the CSG cell is not in the Allowed CSG hst of the UE which sends the detach request 

If the UE initiates a detach procedure in a CSG cell the CSG ID of which is not in the UE's Allowed CSG list, 
the network shall initiate the detach procedure. The MME shall send a DETACH REQUEST message including 
the EMM cause #25, "not authorized for this CSG", to indicate to the UE to remove the CSG ID of the cell where 
the UE has sent the DETACH REQUEST message from the Allowed CSG hst. 

b) Lower layers indication of non-delivered NAS PDU due to handover 

If the DETACH ACCEPT message could not be delivered due to an intra MME handover and the target TA is 
included in the TAJ list, then upon successful completion of the intra MME handover the MME shall retransmit 
the DETACH ACCEPT message. If a failure of the handover procedure is reported by the lower layer and the SI 
signalling connection exists, the MME shall retransmit the DETACH ACCEPT message. 

5.5.2.3 Network initiated detach procedure 
5.5.2.3.1 Network initiated detach procedure initiation 

The network initiates the detach procedure by sending either a DETACH REQUEST message to the UE (see example 
in figure 5.5.2.3.1) or EMM messages (e.g. SERVICE REJECT or TRACKING AREA UPDATE reject) with EMM 
cause #10 "implicitly detached". The network may include an EMM cause IE to specify the reason for the detach 
request. The network shall start timer T3422. In case of detach with Detach type IE indicating "re-attach required" or in 
case of EMM message with EMM cause #10 "implicitly detached", the MME shall store the current EPS security 
context. Otherwise, the current EPS security context is deleted if different from the mapped security context. If the 
detach type IE indicates "re-attach not required" or "re-attach required", the network shall deactivate the EPS bearer 
context(s) for the UE locally and enter state EMM-DEREGISTERED-INITIATED. 

UE MME 



DETACH REQUEST Start T3422 



DETACH ACCEPT ^ gtop T3422 



Figure 5.5.2.3.1 : Network initiated detach procedure 

5.5.2.3.2 Network initiated detach procedure completion by the UE 

When receiving the DETACH REQUEST message and the Detach type IE indicates "re-attach required", the UE shall 
deactivate the EPS bearer context(s) including the default EPS bearer context locally without peer-to-peer signalling 
between the UE and the MME. If the Detach type IE indicates 're-attach required', the UE shall store the current EPS 
security context. The UE shall then send a DETACH ACCEPT message to the network and enter state EMM- 
DEREGISTERED. The UE shall, after the completion of the detach procedure, and the existing NAS signalling 
connection has been released, initiate an attach or combined attach procedure. 

A UE which receives a DETACH REQUEST message with detach type indicating "re-attach required" or "re-attach not 
required" and no EMM cause IE, is detached only for EPS services. 

When receiving the DETACH REQUEST message and the Detach type IE indicates "IMSI detach", the UE shall not 
deactivate the EPS bearer context(s) including the default EPS bearer context. The UE shall set the MM update status to 
U2 NOT UPDATED. A UE may send a DETACH ACCEPT message to the network, and shall re-attach to non-EPS 
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services by performing the combined tracking area updating procedure according to subclause 5.5.3.3, sending a 
TRACKING AREA UPDATE REQUEST message with EPS update type IE indicating "combined TA/LA updating 
with IMS! attach". 

If the UE is attached for EPS and non-EPS services, then if in the UE the timer T3212 is not already running, the timer 
T3212 shall be set to its initial value and restarted if: 

- the Detach type IE indicates "re-attach required" ; or 

- the Detach type IE indicates "re-attach not required" and no EMM cause IE is included. 

When receiving the DETACH REQUEST message and the Detach type IE indicates "re-attach not required", and the 
cause value is not #2, "IMSI unknown in HSS", the UE shall deactivate the EPS bearer context(s) including the default 
EPS bearer context locally without peer-to-peer signalUng between the UE and the MME. The UE shall then send a 
DETACH ACCEPT message to the network and enter state EMM-DEREGISTERED. 

If the detach type IE indicates "IMSI detach" or "re-attach required", then the UE shall ignore the EMM cause IE if 
received. 

If the detach type IE indicates "re-attach not required", the UE shall take the following actions depending on the 
received EMM cause value: 

#2 (IMSI unknown in HSS); 

The UE shall handle the MM parameters update status, TMSI, LAI and ciphering key sequence number as 
specified in 3GPP TS 24.008 [13] for the case when a DETACH REQUEST is received with the GMM cause 
with the same value and with detach type set to "re-attach not required". The USIM shall be considered as 
invalid for non-EPS services until switching off or the UICC containing the USIM is removed. 

The UE is still attached for EPS services in the network. 

#3 (Illegal UE); or 

#6 (Illegal ME); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall 
consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
The UE shall delete the list of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the MM parameters update status, TMSI, 
LAI and ciphering key sequence number and the GMM parameters GMM state, RAI, P-TMSI, P-TMSI 
signature, GPRS ciphering key sequence number and GPRS update status as specified in 3GPP TS 24.008 [13] 
for the case when a DETACH REQUEST is received with the GMM cause with the same value and with detach 
type set to "re- attach not required". The USIM shall also be considered as invalid for non-EPS services until 
switching off or the UICC containing the USIM is removed. 

NOTE: The possibility to configure a UE so that the radio transceiver for a specific radio access technology is not 
active, although it is implemented in the UE, is out of scope of the present specification. 

#7 (EPS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall 
consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
The UE shall delete the list of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, RAI, 
P-TMSI, P-TMSI signature, GPRS ciphering key sequence number and GPRS update status as specified in 
3GPP TS 24.008 [13] for the case when a DETACH REQUEST is received with the GMM cause with the same 
value and with detach type set to "re-attach not required". 

A UE operating in CS/PS mode 1 or CS/PS mode 2 of operation shall set the timer T3212 to its initial value and 
restart it, if not already running. The UE operating in CS/PS mode 1 or CS/PS mode 2 of operation is still IMSI 
attached for non-EPS services in the network. The UE operating in CS/PS mode 1 or CS/PS mode 2 of operation 
shall select GERAN or UTRAN access technology and shall proceed with the appropriate MM specific 
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procedure according to the MM service state. The UE shall not reselect E-UTRAN radio access technology until 
switching off or the UICC containing the USIM is removed. 

#8 (EPS services and non-EPS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSL The UE shall 
consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
The UE shall delete the Ust of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the MM parameters update status, TMSI, 
LAI and ciphering key sequence number and the GMM parameters GMM state, RAI, P-TMSI, P-TMSI 
signature, GPRS ciphering key sequence number and GPRS update status as specified in 3GPP TS 24.008 [13] 
for the case when a DETACH REQUEST is received with the GMM cause with the same value and with detach 
type set to "re-attach not required". The USIM shall also be considered as invalid for non-EPS services until 
switching off or the UICC containing the USIM is removed. 

#11 (PLMN not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSL The UE shall delete 
the hst of equivalent PLMNs, shall reset the attach attempt counter and enter the state EMM- 
DEREGISTERED.PLMN-SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMN list". 

The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the MM parameters update status, TMSI, 
LAI and ciphering key sequence number and the GMM parameters GMM state, RAI, P-TMSI, P-TMSI 
signature, GPRS ciphering key sequence number, GPRS update status and GPRS attach attempt counter as 
specified in 3GPP TS 24.008 [13] for the case when a DETACH REQUEST is received with the GMM cause 
with the same value and with detach type set to "re-attach not required". 

#12 (Tracking area not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSL The UE shall reset 
the attach attempt counter and shaU enter the state EMM-DEREGISTERED.LIMITED-SERVICE. 

The UE shall store the current TAI in the list of "forbidden tracking areas for regional provision of service". 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, RAI, 
P-TMSI, P-TMSI signature, GPRS ciphering key sequence number, GPRS update status and GPRS attach 
attempt counter as specified in 3GPP TS 24.008 [13] for the case when a DETACH REQUEST is received with 
the GMM cause with the same value and with detach type set to "re-attach not required". If the UE is IMSI 
attached for non-EPS services, the UE shall in addition handle the MM parameters update status, TMSI, LAI, 
ciphering key sequence number and location update attempt counter as specified in 3GPP TS 24.008 [13] for the 
case when a DETACH REQUEST is received with the GMM cause with the same value and with detach type set 
to "re-attach not required". 

#13 (Roaming not allowed in this tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI Ust and KSI. The UE shall delete 
the list of equivalent PLMNs, reset the attach attempt counter and shall change to state EMM- 
DEREGISTERED.PLMN-SEARCH. 

The UE shall store the current TAI in the list of "forbidden tracking areas for roaming". 
The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6] 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, RAI, 
P-TMSI, P-TMSI signature, GPRS ciphering key sequence number, GPRS update status and GPRS attach 
attempt counter as specified in 3GPP TS 24.008 [13] for the case when a DETACH REQUEST is received with 
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the GMM cause with the same value and with detach type set to "re-attach not required". If the UE is IMSI 
attached for non-EPS services, the UE shall in addition handle the MM parameters update status, TMSI, LAI, 
ciphering key sequence number and location update attempt counter and as specified in 3GPP TS 24.008 [13] for 
the case when a DETACH REQUEST is received with the GMM cause with the same value and with detach 
type set to "re-attach not required". 

#14 (EPS services not allowed in this PLMN); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). Furthermore the UE shall delete any GUTI, last visited registered TAI, TAI list and KSI. The 
UE shall reset the attach attempt counter and shall enter the state EMM-DEREGISTERED.PLMN-SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMNs for GPRS service" list. 

A UE operating in CS/PS mode 1 or CS/PS mode 2 of operation is still IMSI attached for non-EPS services. If 
the timer T3212 is not already running in the UE, the UE shall set the timer T3212 to its initial value and restart 
it. 

A UE operating in CS/PS mode 1 of operation may select GERAN or UTRAN radio access technology and 
proceed with the appropriate MM specific procedure according to the MM service state. In this case the UE shall 
not reselect E-UTRAN radio access technology for the duration the UE is on the PLMN or an equivalent PLMN. 

A UE in CS/PS mode 1 of operation may perform a PLMN selection according to 3GPP TS 23.122 [6]. 

A UE in PS mode of operation or in CS/PS mode 2 of operation shall perform a PLMN selection according to 
3GPPTS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, RAI, P-TMSI, P-TMSI signature, GPRS ciphering key sequence number and GPRS attach attempt 
counter as specified in 3GPP TS 24.008 [13] for the case when a DETACH REQUEST is received with the 
GMM cause with the same value and with detach type set to "re-attach not required". 

#15 (No suitable cells in tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall reset 
the attach attempt counter and shall enter the state EMM-DEREGISTERED.LIMITED-SERVICE. 

The UE shall store the current TAI in the list of "forbidden tracking areas for roaming". 

The UE shall search for a suitable cell in another tracking area or in another location area in the same PLMN 
according to 3GPP TS 36.304 [21]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, RAI, 
P-TMSI, P-TMSI signature, GPRS ciphering key sequence number, GPRS update status and GPRS attach 
attempt counter as specified in 3GPP TS 24.008 [13] for the case when a DETACH REQUEST is received with 
the GMM cause with the same value and with detach type set to "re-attach not required". If the UE is IMSI 
attached for non-EPS services, the UE shall in addition handle the MM parameters update status, TMSI, LAI, 
ciphering key sequence number and location update attempt counter as specified in 3GPP TS 24.008 [13] for the 
case when a DETACH REQUEST is received with the GMM cause with the same value and with detach type set 
to "re-attach not required". 

#25 (Not authorized for this CSG); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). The UE shall reset the attach attempt counter and shall enter the state EMM- 
DEREGISTERED.LIMITED-SERVICE. 

The UE shall remove the CSG ID of the cell where the UE has received the DETACH REQUEST message from 
the Allowed CSG list. 

The UE shall search for a suitable cell in the same PLMN according to 3GPP TS 36.304 [21]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status and GPRS attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when a 
DETACH REQUEST is received with GMM cause with the same value and with detach type set to "re-attach 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 



75 



ETSI TS 124 301 V8.2.1 (2009-06) 



not required". If the UE is IMSI attached for non-EPS services, the UE shall in addition handle the MM 
parameters update status and location update attempt counter as specified in 3GPP TS 24.008 [13] for the case 
when a DETACH REQUEST is received with the GMM cause with the same value and with detach type set to 
"re-attach not required". 

Other EMM cause values or if no EMM cause IE is included is considered as abnormal cases. The behaviour of the UE 
in those cases is described in subclause 5.5.2.3.4. 

5.5.2.3.3 Network initiated detacli procedure completion by tine network 

The network shall, upon receipt of the DETACH ACCEPT message, stop timer T3422 and enter state EMM- 
DEREGISTERED. 

5.5.2.3.4 Abnormal cases in the UE 

The following abnormal cases can be identified: 

a) Transmission failure of DETACH ACCEPT message indication from lower layers 

The detach procedure shall be progressed and the UE shall send the DETACH ACCEPT message. 

b) DETACH REQUEST, other EMM cause values than those treated in subclause 5.5.2.3.2 or no EMM cause IE is 
included, and the Detach type IE indicates "re-attach not required" 

The UE shall delete any GUTI, TAI list, last visited registered TAI, Ust of equivalent PLMNs, KSI, shall set the 
update status to EU2 NOT UPDATED and shall start timer T3402. The UE may enter the state EMM- 
DEREGISTERED.PLMN-SEARCH in order to perform a PLMN selection according to 3GPP TS 23.122 [6]; 
otherwise the UE shall enter the state EMM-DEREGISTERED.ATTEMPTING-TO- ATTACH. 

If A/Gb mode or lu mode is supported by the UE, the UE shall set the GPRS update status to GU2 NOT 
UPDATED and shall delete the GMM parameters P-TMSI, P-TMSI signature, RAI, GPRS ciphering key 
sequence number and shall enter the state GMM-DEREGISTERED. 

5.5.2.3.5 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) T3422 time-out 

On the first expiry of the timer, the network shall retransmit the DETACH REQUEST message and shall start 
timer T3422. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3422, the detach 
procedure shall be aborted and the network changes to state EMM-DEREGISTERED. 

b) Lower layer failure 

The detach procedure is aborted and the network changes to state EMM-DEREGISTERED. 

c) Detach procedure collision 

If the network receives a DETACH REQUEST message with "switch off" indication, before the network 
initiated GPRS detach procedure has been completed, both procedures shall be considered completed. 

If the network receives a DETACH REQUEST message without "switch off indication, before the network 
initiated detach procedure has been completed, the network shall send a DETACH ACCEPT message to the UE. 

d) Detach and attach procedure collision 

If the network receives an ATTACH REQUEST message before the network initiated detach procedure with 
detach type "re-attach not required" has been completed, the network shall ignore the ATTACH REQUEST 
message. If the Detach type IE, sent in the DETACH REQUEST message, indicates "re-attach required" the 
detach procedure is aborted and the attach procedure shall be progressed after the EPS bearer context(s) have 
been deleted. If the Detach type IE, sent in DETACH REQUEST message, indicates "IMSI detach" the detach 
procedure is aborted and the attach procedure shall be progressed. 

e) Detach and tracking area updating procedure colUsion 
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If the Detach type IE, sent in DETACH REQUEST message, indicates "re-attach required" or "re-attach not 
required" and the network receives a TRACKING AREA UPDATE REQUEST message before the network 
initiated detach procedure has been completed, the detach procedure shall be progressed, i.e. the TRACKING 
AREA UPDATE REQUEST message shall be ignored. 

If the Detach type IE, sent in DETACH REQUEST message, indicates "IMSI detach" and the network receives a 
TRACKING AREA UPDATE REQUEST message before the network initiated detach procedure has been 
completed, the network shall abort the detach procedure, shall stop T3422 and shall progress the tracking area 
updating procedure. 

f) Detach and service request procedure collision 

If the network receives a SERVICE REQUEST message before the network initiated detach procedure has been 
completed (e.g. the DETACH REQUEST message is pending to be sent to the UE), the network shall progress 
the both procedures. 

g) Lower layers indication of non-delivered NAS PDU due to handover 

If the DETACH REQUEST message could not be delivered due to an intra MME handover and the target TA is 
included in the TAI list, then upon successful completion of the intra MME handover the MME shall retransmit 
the DETACH REQUEST message. If a failure of the handover procedure is reported by the lower layer and the 
S 1 signalUng connection exists, the MME shall retransmit the DETACH REQUEST message. 

5.5.3 Tracking area updating procedure (S1 mode only) 
5.5.3.1 General 

The tracking area updating procedure is always initiated by the UE and is used for the following purposes: 

- normal tracking area updating to update the registration of the actual tracking area of a UE in the network; 

- combined tracking area updating to update the registration of the actual tracking area for a UE in CS/PS mode 1 
or CS/PS mode 2 of operation; 

- periodic tracking area updating to periodically notify the availability of the UE to the network; 

- IMSI attach for non-EPS services when the UE is attached for EPS services. This procedure is used by a UE in 
CS/PS mode 1 or CS/PS mode 2 of operation; 

in various cases of inter-system change from lu mode to SI mode or from A/Gb mode to SI mode (for details 
see subclauses 5.5.3.2.2 and subclause 5.5.3.3.2); 

- SlOl mode to SI mode inter-system change; 

- MME load balancing; 

- to update certain UE specific parameters in the network (for details see subclauses 5.5.3.2.2 and 
subclause 5.5.3.3.2); 

- recovery from certain error cases (for details see subclauses 5.5.3.2.2 and subclause 5.5.3.3.2); 

- to indicate that the UE enters SI mode after CS fallback or IxCS fallback; and 

- to indicate to the network that the UE has selected a CSG cell whose CSG identity is not included in the UE's 
Allowed CSG Ust. 

During the tracking area updating procedure, the MME may initiate an authentication procedure and setup security 
mode. 

A UE initiating the tracking area updating procedure in EMM-IDLE mode may request the network to re-establish the 
radio and SI bearers for all active EPS bearer contexts during the procedure. 

In a shared network, the UE shall choose one of the PLMN identities as specified in 3GPP TS 23.122 [6]. The UE shall 
construct the TAI of the cell from this chosen PLMN identity and the TAC received on the broadcast system 
information. The chosen PLMN identity shaU be indicated to the E-UTRAN (see 3GPP TS 36.331 [22]). Whenever a 
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TRACKING AREA UPDATING REJECT message with the EMM cause #1 1 "PLMN not allowed" is received by the 
UE, the chosen PLMN identity shall be stored in the "forbidden PLMN list". Whenever a TRACKING AREA 
UPDATING REJECT message is received by the UE with the EMM cause #13 "roaming not allowed in this tracking 
area", #12 "tracking area not allowed", or #15 "no suitable cells in tracking Area", the constructed TAI shall be stored in 
the suitable list. 

A tracking area updating attempt counter is used to limit the number of subsequently rejected tracking area update 
attempts. The tracking area updating attempt counter shall be incremented as specified in subclause 5.5.3.2.6. 
Depending on the value of the tracking area updating attempt counter, specific actions shall be performed. The tracking 

area updating attempt counter shall be reset when: 

- an attach or combined attach procedure is successfully completed; 

- a normal or periodic tracking area updating or a combined tracking area updating procedure is successfully 
completed; or 

- a normal or periodic tracking area updating or a combined tracking area updating procedure is rejected with 
EMM cause #11, #12, #13, #14, #15 or #25. 

Additionally the tracking area updating attempt counter shall be reset when the UE is in substate EMM- 
REGISTERED. ATTEMPTING-TO-UPD ATE or EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM, and: 

- a new tracking area is entered; or 
timer T3402 expires. 

5.5.3.2 Normal and periodic tracking area updating procedure 

5.5.3.2.1 General 

The periodic tracking area updating procedure is controlled in the UE by timer T3412. When timer T3412 expires, the 
periodic tracking area updating procedure is started. Start and reset of timer T3412 is described in subclause 5.3.5. 

5.5.3.2.2 Normal and periodic tracking area updating procedure initiation 

The UE in state EMM-REGISTERED shall initiate the tracking area updating procedure by sending a TRACKING 
AREA UPDATE REQUEST message to the MME, 

a) when the UE detects entering a tracking area that is not in the list of tracking areas that the UE previously 
registered in the MME; 

b) when the periodic tracking area updating timer T3412 expires; 

c) when the UE enters EMM-REGISTERED.NORMAL-SERVICE and the UE's TIN indicates "P-TMSI"; 

d) when the UE performs an inter-system change from SlOl mode to SI mode and has no user data pending; 

e) when the UE receives an indication from the lower layers that the RRC connection was released with cause "load 
balancing TAU required"; 

f) when the UE deactivated EPS bearer context(s) locally while in EMM-REGISTERED.NO-CELL- 
AVAILABLE, and then returns to EMM-REGISTERED.NORMAL-SERVICE; 

g) when the UE changes the UE network capability information or the MS network capability information or both; 

h) when the UE changes the UE specific DRX parameter; 

i) when the UE receives an indication of "RRC Connection failure" from the lower layers and has no user uphnk 
data pending; 

j) when the UE enters SI mode after IxCS fallback; or 

k) when the UE has selected a CSG cell whose CSG identity is not included in the UE's Allowed CSG list. 
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For all cases except case b), the UE shall set the EPS update type IE to "TA updating". For case b), the UE shall set the 

EPS update type IE to "periodic updating". 

When the UE has user data pending and performs an inter-system change from SlOl mode to SI mode to a tracking 
area included in the TAI Ust stored in the UE, the UE shall perform a service request procedure instead of a tracking 
area updating procedure. 

When initiating a tracking area updating procedure while in S 1 mode, the UE shall use the current EPS NAS integrity 
key to integrity protect the TRACKING AREA UPDATE REQUEST message. 

In order to indicate its UE specific DRX parameter while in E-UTRAN coverage, the UE shall send the TRACKING 
AREA UPDATE REQUEST message containing the UE specific DRX parameter in the DRX parameter IE to the 
network, with the exception of the case if the UE had indicated its DRX parameter (3GPP TS 24.008 [13]) to the 
network while in GERAN or UTRAN coverage. In this case, when the UE enters E-UTRAN coverage and initiates a 
tracking area updating procedure, the UE shall not include the UE specific DRX parameter in the DRX parameter IE in 
the TRACKING AREA UPDATE REQUEST message. 

After sending the TRACKING AREA UPDATE REQUEST message to the MME, the UE shall start timer T3430 and 
enter state EMM-TRACKING-AREA-UPDATING-INITIATED (see example in figure 5.5.3.2.2). If timer T3402 is 
currently running, the UE shall stop timer T3402. If timer T341 1 is currently running, the UE shall stop timer T341 1 . If 
timer T3442 is currently rvmning, the UE shall stop timer T3442. 

If the UE supports neither A/Gb mode nor lu mode, the UE shall include a vaUd GUTI in the Old GUTI IE in the 
TRACKING AREA UPDATE REQUEST message. 

If the UE supports A/Gb mode or lu mode, the UE shall handle the Old GUTI IE as follows: 

- If the TIN indicates "P-TMSI" and the UE holds a vahd P-TMSI and RAl, the UE shall map the P-TMSl and 
RAI into the Old GUTI IE. Additionally, if the UE holds a valid GUTI, the UE shaU indicate the GUTI in the 
Additional GUTI IE. 

NOTE: The mapping of the P-TMSl and RAl to the GUTI is specified in 3GPP TS 23.003 [2]. 

- If the TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI, the UE shall indicate the 
GUTI in the Old GUTI IE. 

In the TRACKING AREA UPDATE REQUEST message the UE shall set the value of the EPS update type IE to 
"periodic updating", if the procedure initiated due to expiry of T3412; otherwise, the UE shall set the value to "TA 
updating". If a UE has uplink user data pending when it initiates the tracking area updating procedure, or uplink 
signalling not related to the tracking area updating procedure, it may also set an "active" flag in the TRACKING AREA 
UPDATE REQUEST message to indicate the request to establish the user plane to the network and to keep the NAS 
signalling connection after the completion of the tracking area updating procedure. 

If the UE has a current EPS security context, the UE shall include the eKSI (either KSIasme or KSIsgsn) in the NAS 
Key Set Identifier IE in the TRACKING AREA UPDATE REQUEST message. Otherwise, the UE shall set the NAS 
Key Set Identifier IE to the value "no key is available". If the UE has a current EPS security context, the UE shall 
integrity protect the TRACKING AREA UPDATE REQUEST message with the current EPS security context. 
Otherwise the UE shall not integrity protect the TRACKING AREA UPDATE REQUEST message. 

When the tracking area updating procedure is initiated in EMM-IDLE mode to perform an inter-system change from 
A/Gb mode or lu mode to SI mode and the TIN is set to "P-TMSI", the UE shall include the GPRS ciphering key 
sequence number applicable for A/Gb mode or lu mode and a nonceuE in the TRACKING AREA UPDATE REQUEST 
message. 

When the tracking area updating procedure is initiated in EMM-CONNECTED mode to perform an inter-system 
change from A/Gb mode or lu mode to SI mode, the UE shall derive the EPS NAS keys from the mapped K'asme using 
the selected NAS algorithms, nonccMME and KSIsgsn (to be associated with the mapped K'asme) provided by lower 
layers as indicated in 3GPP TS 33.401 [19]. The UE shall reset the NAS COUNT of the mapped EPS security context 
which shall be taken into use. If the UE has a non-current native EPS security context, the UE shall include the KSIasme 
in the Non-current native NAS key set identifier IE and its associated GUTI, as specified above, either in the Old GUTI 
IE or in the Additional GUTI IE of the TRACKING AREA UPDATE REQUEST message. The UE shall set the TSC 
flag in the Non-current native NAS key set identifier IE to "native security context". 
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When the tracking area updating procedure is initiated in EMM-IDLE mode, the UE may also include an EPS bearer 
context status IE in the TRACKING AREA UPDATE REQUEST message, indicating which EPS bearer contexts are 
active in the UE. 

If the UE initiates the first tracking area updating procedure following an attach in A/Gb mode or lu mode, the UE shall 
include a UE radio capability information update needed IE in the TRACKING AREA UPDATE REQUEST message. 



UE MME 



TRACKING AREA UPDATE REQUEST 
Start T3430 



TRACKING AREA UPDATE ACCEPT 

Stop T3430 



If GUTI allocated, TRACKING AREA UPDATE COMPLETE 

► Stop T3450 

OR 



TRACKING AREA UPDATE REQUEST 
Start T3430 



TRACKING AREA UPDATE REJECT 

Stop T3430 

Figure 5.5.3.2.2.1: Tracking area updating procedure 

5.5.3.2.3 EMM common procedure initiation 

When the network receives a TRACKING AREA UPDATE REQUEST message containing the Old GUTI IE and the 
Additional GUTI IE with the same encoded mobile identity type "GUTI", but indicating different mobile identities, the 
network shall regard the former one as a P-TMSI and RAI and the latter one as a GUTI. 

The network may initiate EMM common procedures, e.g. the EMM authentication and security mode control 
procedures. 

5.5.3.2.4 Normal and periodic tracking area updating procedure accepted by the network 

If the tracking area update request has been accepted by the network, the MME shall send a TRACKING AREA 
UPDATE ACCEPT message to the UE. If the MME assigns a new GUTI for the UE, a GUTI shall be included in the 
TRACKING AREA UPDATE ACCEPT message. In this case, the MME shall start timer T3450 and enter state EMM- 
COMMON-PROCEDURE-INITIATED as described in subclause 5.4.1. The MME may include a new TAI list for the 
UE in the TRACKING AREA UPDATE ACCEPT message. 

If the UE has included the UE network capability IE or the MS network capability IE or both in the TRACKING AREA 
UPDATE REQUEST message, the MME shall store all octets received from the UE, up to the maximum length defined 
for the respective information element. 

NOTE 1: This information is forwarded to the new MME during inter-MME handover or to the new SGSN during 
inter-system handover to A/Gb mode or lu mode. 

If a UE radio capability information update needed IE is included in the TRACKING AREA UPDATE REQUEST 
message, the MME shall delete the stored UE radio capability information, if any. 



If GUTI allocated, 
Start T3450 
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If the UE specific DRX parameter was included in the DRX Parameter IE in the TRACKING AREA UPDATE 
REQUEST message, the network shall replace any stored UE specific DRX parameter with the received parameter and 
use it for the downlink transfer of signalling and user data. 

If an EPS bearer context status IE is included in the TRACKING AREA UPDATE REQUEST message, the MME shall 
deactivate all those EPS bearer contexts locally (without peer-to-peer signalling between the MME and the UE) which 
are active on the network side, but are indicated by the UE as being inactive. Additionally, the MME shall include an 
EPS bearer context status IE in the TRACKING AREA UPDATE ACCEPT message, indicating which EPS bearer 
contexts are active in the MME. 

For a shared network, the TAIs included in the TAI list can contain different PLMN identities. The MME indicates the 
selected core network operator PLMN identity to the UE in the GUTI (see 3GPP TS 23.251 [8A]). 

If the "active" flag is included in the TRACKING AREA UPDATE REQUEST message, the MME shaU re-establish 
the radio and SI bearers for all active EPS bearer contexts. 

Upon receiving a TRACKING AREA UPDATE ACCEPT message, the UE shall stop timer T3430, reset the tracking 
area updating attempt counter, enter state EMM-REGISTERED and set the EPS update status to EUl UPDATED. If the 
message contains a GUTI, the UE shall use this GUTI as new temporary identity for EPS services and shall store the 
new GUTI. If no GUTI was included by the MME in the TRACKING AREA UPDATE ACCEPT message, the old 
GUTI shall be used. If the UE receives a new TAI list in the TRACKING AREA UPDATE ACCEPT message, the UE 
shall consider the new TAI Ust as valid and the old TAI list as invalid; otherwise, the UE shall consider the old TAI Ust 
as valid. 

If the UE had initiated TAU due to a change in UE network capability or change in DRX parameters or both, the UE 
shall locally deactivate ISR by setting TIN value to "GUTI". 

If an EPS bearer context status IE is included in the TRACKING AREA UPDATE ACCEPT message, the UE shall 
deactivate all those EPS bearers contexts locally (without peer-to-peer signalling between the UE and the MME) which 
are active in the UE, but are indicated by the MME as being inactive. 

The MME may also include of list of equivalent PLMNs in the TRACKING AREA UPDATE ACCEPT message. Each 
entry in the Ust contains a PLMN code (MCC-i-MNC). The UE shall store the list as provided by the network, after 
having removed from the list any PLMN code that is already in the list of forbidden PLMNs. In addition, the UE shall 
add to the stored list the PLMN code of the registered PLMN that sent the Ust. The UE shall replace the stored list on 
each receipt of the TRACKING AREA UPDATE ACCEPT message. If the TRACKING AREA UPDATE ACCEPT 
message does not contain a list, then the UE shaU delete the stored Ust. 

The network may also indicate in the EPS update result IE in the TRACKING AREA UPDATE ACCEPT message that 
ISR is active. If the TRACKING AREA UPDATE ACCEPT message contains: 

i) no indication that ISR is activated, the UE shaU set the TIN to "GUTI"; 

ii) an indication that ISR is activated, the UE shall regard a previously assigned P-TMSI and RAI as valid and 
registered with the network. If the TIN currently indicates "P-TMSI", the UE shall set the TIN to "RAT-related 
TMSI". 

If the UE supporting CSG selection has attempted manual CSG selection, the UE, when receiving the TRACKING 
AREA UPDATE ACCEPT message, shall check if the CSG ID of the cell where the UE has sent the TRACKING 
AREA UPDATE REQUEST message is contained in the Allowed CSG Ust. If not, the UE shall add that CSD ID to the 
AUowed CSG Ust. 

If tUe TRACKING AREA UPDATE ACCEPT message contained a GUTI, the UE shaU return a TRACKING AREA 
UPDATE COMPLETE message to tUe MME to acknowledge tUe received GUTI. 

Upon receiving a TRACKING AREA UPDATE COMPLETE message, the MME shall stop timer T3450, and shall 
consider the GUTI sent in the TRACKING AREA UPDATE ACCEPT message as vaUd. 

For inter-system change from A/Gb mode to S 1 mode or lu mode to S 1 mode in EMM-IDLE mode, if the UE has 
included an eKSI in the NAS Key Set Identifier IE indicating a current EPS security context in the TRACKING AREA 
UPDATE REQUEST message, the MME shaU take one of the foUowing actions: 

- if the MME retrieves the current EPS security context as indicated by the eKSI and GUTI sent by the UE, the 
MME shaU integrity cUeck the TRACKING AREA UPDATE REQUEST message using the current EPS 
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security context and integrity protect the TRACKING AREA UPDATE ACCEPT message using the current 

security context; or 

- if the MME can not retrieve the current EPS security context as indicated by the eKSI and GUTI sent by the UE, 
the MME shall perform a security mode control procedure to indicate the use of the new mapped EPS security 
context to the UE (see subclause 5.4.3.2). 

NOTE 2: This does not preclude the option for the MME to perform an authentication procedure and create a new 
native EPS security context. 

For inter-system change from A/Gb mode to S 1 mode or lu mode to S 1 mode in EMM-IDLE mode, if the UE has not 
included a valid eKSI in the NAS Key Set Identifier IE in the TRACKING AREA UPDATE REQUEST message, the 
MME shall perform a security mode control procedure to indicate the use of the new mapped EPS security context to 
the UE (see subclause 5.4.3.2). 

NOTE 3: This does not preclude the option for the MME to perform an authentication procedure and create a new 

native EPS security context. 

For inter-system change from A/Gb mode to SI mode or lu mode to SI mode in EMM-CONNECTED mode, the MME 
shall integrity check TRACKING AREA UPDATE REQUEST message using the current K'ASMEas derived when 
triggering the handover to E-UTRAN (see subclause 4.4.2.1). The MME shall verify the received UE security 
capabilities in the TRACKING AREA UPDATE REQUEST message. The MME shall then take one of the following 
actions: 

- if the TRACKING AREA UPDATE REQUEST does not contain a valid KSIasme the MME shall remove any 
native EPS security context for any GUTI for this UE. The MME shall then integrity protect and cipher the 
TRACKING AREA UPDATE ACCEPT message using the security context based on K'asme and take the 
mapped EPS security context into use; or- if the TRACKING AREA UPDATE REQUEST contains a valid 
KSIasme the MME may initiate a security mode control procedure to take the native EPS security context into 
use. 

5.5.3.2.5 Normal and periodic tracking area updating procedure not accepted by tine 

network 

If the tracking area updating cannot be accepted by the network, the MME sends a TRACKING AREA UPDATE 
REJECT message to the UE including an appropriate EMM cause value. 

Upon receiving the TRACKING AREA UPDATE REJECT message, the UE shall stop timer T3430, stop any 
transmission of user data, and take the following actions depending on the EMM cause value received. 

#3 (Illegal UE); or 

#6 (Illegal ME); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall 
consider the USIM as invalid for EPS services until switching off or the UlCC containing the USIM is removed. 
The UE shall delete the hst of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSI, P-TMSl signature, RAI and GPRS ciphering key sequence number and the MM 
parameters update status, TMSI, LAI and ciphering key sequence number as specified in 3GPP TS 24.008 [13] 
for the case when the normal routing area updating procedure is rejected with the GMM cause with the same 
value. The USIM shall be considered as invalid also for non-EPS services until switching off or the UICC 
containing the USIM is removed. 

NOTE: The possibility to configure a UE so that the radio transceiver for a specific radio access technology is not 
active, although it is implemented in the UE, is out of scope of the present specification. 

#7 (EPS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI hst and KSI. The UE shall 
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consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
The UE shall delete the list of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as specified in 
3GPP TS 24.008 [13] for the case when the normal routing area updating procedure is rejected with the GMM 

cause with the same value. 

#9 (UE identity cannot be derived by the network); 

The UE shall set the EPS update status to EU2 NOT UPDATED (and shall store it according to 

subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAl list and KSI. The UE shall delete 

the list of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

Subsequently, the UE shall automatically initiate the attach procedure. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSl, P-TMSl signature, RAI and GPRS ciphering key sequence number as specified in 
3GPP TS 24.008 [13] for the case when the normal routing area updating procedure is rejected with the GMM 
cause with the same value. 

#10 (Implicidy detached); 

The UE shall delete the hst of equivalent PLMNs and shall enter the state EMM-DEREGISTERED.NORMAL- 
SERVICE. The UE shall delete the mapped EPS security context if any. The UE shall then perform a new attach 
procedure. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM state as specified in 

3GPP TS 24.008 [13] for the case when the normal routing area updating procedure is rejected with the GMM 

cause with the same value. 

#11 (PLMN not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall reset 
the tracking area updating attempt counter, delete the list of equivalent PLMNs and enter the state EMM- 
DEREGISTERED.PLMN-SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMN list". 

The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSl, P-TMSl signature, RAI, GPRS ciphering key sequence number and routing area updating 
attempt counter and the MM parameters update status, TMSI, LAI, ciphering key sequence number and the 
location update attempt counter as specified in 3GPP TS 24.008 [13] for the case when the normal routing area 
updating procedure is rejected with the GMM cause with the same value and no RR connection exists. 

#12 (Tracking area not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall reset 
the tracking area updating attempt coimter and shall enter the state EMM-DEREGISTERED .LIMITED- 
SERVICE. 

The UE shall store the current TAI in the list of "forbidden tracking areas for regional provision of service". 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSl, P-TMSI signature, RAI, GPRS ciphering key sequence number and routing area updating 
attempt counter as specified in 3GPP TS 24.008 [13] for the case when the normal routing area updating 
procedure is rejected with the GMM cause with the same value. 

#13 (Roaming not allowed in this tracking area); 
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The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete the list of equivalent PLMNs. The UE shall reset the tracking area updating 
attempt counter and shall change to state EMM-REGISTERED.PLMN-SEARCH. 

The UE shall store the current TAI in the list of "forbidden tracking areas for roaming" and shall remove the 
current TAI from the stored TAI Ust if present. 

The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 

update status and routing area updating attempt counter as specified in 3GPP TS 24.008 [13] for the case when 
the normal routing area updating procedure is rejected with the GMM cause with the same value. 

#14 (EPS services not allowed in this PLMN); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1 .3.3). Furthermore the UE shall delete any GUTI, last visited registered TAI, TAI list and KSI. The 
UE shall reset the tracking area updating attempt counter and shall enter the state EMM- 
DEREGISTERED.PLMN-SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMNs for GPRS service" list. 
The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSI, P-TMSI signature, RAl, GPRS ciphering key sequence number and routing area updating 
attempt counter as specified in 3GPP TS 24.008 [13J for the case when the normal routing area updating 
procedure is rejected with the GMM cause with the same value. 

#15 (No suitable cells in tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). The UE shall reset the tracking area updating attempt coimter and shall enter the state EMM- 
REGIS TERED . LIMITED - SERVICE. 

The UE shall store the current TAI in the list of "forbidden tracking areas for roaming" and shall remove the 
current TAI from the stored TAI Ust if present. 

The UE shall search for a suitable cell in another tracking area or in another location area in the same PLMN 
according to 3GPP TS 36.304 [21]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 

update status and routing area updating attempt counter as specified in 3GPP TS 24.008 [13] for the case when 
the normal routing area updating procedure is rejected with the GMM cause with the same value. 

#25 (Not authorized for this CSG); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). The UE shall reset the tracking area updating attempt counter and shall enter the state EMM- 
REGISTERED.LIMITED-SERVICE. 

The UE shall remove the CSG ID of the cell where the UE has sent the TRACKING AREA UPDATE 
REQUEST message if the CSG ID is contained in the Allowed CSG list. 

The UE shall search for a suitable cell in the same PLMN according to 3GPP TS 36.304 [21]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status and routing area updating attempt counter as specified in 3GPP TS 24.008 [13] for the case when 
the normal routing area updating procedure is rejected with the GMM cause with the same value. 

#40 (No EPS bearer context activated); 

The UE shall delete the list of equivalent PLMNs and deactivate all the EPS bearer contexts locally, if any, and 
shall enter the state EMM-DEREGISTERED .NORMAL-SERVICE. The UE shall then perform a new attach 
procedure. 
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Other values are considered as abnormal cases. The specification of the UE behaviour in those cases is described in 
subclause 5.5.3.2.6. 

5.5.3.2.6 Abnormal cases in the UE 

The following abnormal cases can be identified: 

a) Access barred because of access class barring or NAS signalUng cormection establishment rejected by the 
network 

If access is barred for "signalling" (see 3GPP TS 36.331 [22]), the tracking area updating procedure shall not be 
started. The UE stays in the current serving cell and applies the normal cell reselection process. The tracking 
area updating procedure is started as soon as possible and if still necessary, e.g. when access for "signalling" is 
granted on the current cell or when the UE moves to a cell where access for "signalling" is granted. 

b) Lower layer failure or release of the NAS signalUng connection before the TRACKING AREA UPDATE 
ACCEPT or TRACKING AREA UPDATE REJECT message is received 

The tracking area updating procedure shall be aborted, and the UE shall proceed as described below. 

c) T3430 timeout 

The UE shall abort the procedure and proceed as described below. The NAS signalling connection shall be 
released locally. 

d) TRACKING AREA UPDATE REJECT, other causes than those treated in subclause 5.5.3.2.5 

Upon reception of the EMM causes #95, #96, #97, #99 and #11 1 the UE should set the tracking area updating 
attempt counter to 5. The UE shall proceed as described below. 

e) Change of cell into a new tracking area 

If a cell change into a new tracking area occurs before the tracking area updating procedure is completed, the 
tracking area updating procedure shall be aborted and re-initiated immediately. The UE shall set the EPS update 
status to EU2 NOT UPDATED. 

f) Tracking area updating and detach procedure collision 

If the UE receives a DETACH REQUEST message before the tracking area updating procedure has been 
completed, the tracking area updating procedure shall be aborted and the detach procedure shall be progressed. 

g) Tracking area updating and GUTI reallocation procedure collision 

If the UE receives a GUTI REALLOCATION COMMAND message before the tracking area updating 
procedure has been completed, this message shall be ignored and the tracking area updating procedure shall be 
progressed. 

h) Transmission failure of TRACKING AREA UPDATE REQUEST message indication from lower layers 

The tracking area updating procedure shall be aborted and re-initiated immediately. The UE shall set the EPS 
update status to EU2 NOT UPDATED. 

i) Transmission failure of TRACKING AREA UPDATE COMPLETE message indication with TAI change from 

lower layers 

If the current TAI is not in the TAI list, the tracking area updating procedure shall be aborted and re-initiated 
immediately. The UE shall set the EPS update status to EU2 NOT UPDATED. 

If the current TAI is still part of the TAI list, it is up to the UE implementation how to re-run the ongoing 
procedure. 

j) Transmission failure of TRACKING AREA UPDATE COMPLETE message indication without TAI change 
from lower layers 

It is up to the UE implementation how to re-run the ongoing procedure. 
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For the cases b, c, d, e, and f, the UE shall stop any ongoing transmission of user data. 

For the cases b, c and d the UE shall proceed as foUows: 

Timer T3430 shall be stopped if stiU running. The tracking area updating attempt counter shall be incremented, 
unless it was already set to 5. 

If the tracking area updating attempt counter is less than 5, and the TAI of the current serving cell is included in 
the TAI list and the EPS update status is equal to EUl UPDATED: 

- the UE shall keep the EPS update status to EU 1 UPDATED and enter state EMM- 
REGISTERED.NORMAL-SERVICE. The UE shall start timer T3411. When timer T3411 expires the 
tracking area updating procedure is triggered again. 

If the tracking area updating attempt counter is less than 5, and the TAI of the current serving cell is not included 
in the TAI list or the EPS update status is different to EUl UPDATED: 

- the UE shall start timer T3411, shall set the EPS update status to EU2 NOT UPDATED and change to state 
EMM-REGISTERED. ATTEMPTING-TO-UPD ATE. When timer T341 1 expires the tracking area updating 
procedure is triggered again. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GPRS update status as 
specified in 3GPP TS 24.008 [13] for the abnormal case when a normal or periodic routing area updating 
procedure fails and the routing area updating attempt counter is less than 5 and the GPRS update status is 
different from GUI UPDATED. 

If the tracking area updating attempt counter is equal to 5: 

- the UE shall start timer T3402, shall set the EPS update status to EU2 NOT UPDATED, shall delete the list 
of equivalent PLMNs and shall change to state EMM-REGISTERED. ATTEMPTING-TO-UPD ATE or 
optionally to EMM-REGISTERED.PLMN-SEARCH in order to perform a PLMN selection according to 
3GPPTS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GPRS update status as 
specified in 3GPP TS 24.008 [13] for the abnormal case when a normal or periodic routing area updating 
procedure fails and the routing area updating attempt counter is equal to 5. 

5.5.3.2.7 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) If a lower layer failure occurs before the message TRACKING AREA UPDATE COMPLETE has been received 
from the UE and a GUTI has been assigned, the network shall abort the procedure and shall consider both, the 
old and new GUTI as valid until the old GUTI can be considered as invalid by the network (see 

subclause 5.4.1.4). Diu-ing this period the network may use the identification procedure followed by a GUTI 
reallocation procedure if the old GUTI is used by the UE in a subsequent message. 

The network may page with IMSI if paging with old and new S-TMSI fails. Paging with IMSI causes the UE to 
re-attach as described in subclause 5.6.2.2.2. 

b) Protocol error 

If the TRACKING AREA UPDATE REQUEST message has been received with a protocol error, the network 
shall return a TRACKING AREA UPDATE REJECT message with one of the following EMM cause values: 

#96: invalid mandatory information element error; 

#99: information element non-existent or not implemented; 

#100: conditional IE error; or 

#111: protocol error, unspecified. 

c) T3450 time-out 
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On the first expiry of the timer, the network shall retransmit the TRACKING AREA UPDATE ACCEPT 
message and shall reset and restart timer T3450. The retransmission is performed four times, i.e. on the fifth 
expiry of timer T3450, the tracking area updating procedure is aborted. Both, the old and the new GUTI shall be 
considered as valid until the old GUTI can be considered as invalid by the network (see subclause 5.4.1.4). 
During this period the network acts as described for case a above. 

d) TRACKING AREA UPDATE REQUEST received after the TRACKING AREA UPDATE ACCEPT message 
has been sent and before the TRACKING AREA UPDATE COMPLETE message is received 

- If one or more of the information elements in the TRACKING AREA UPDATE REQUEST message differ 
from the ones received within the previous TRACKING AREA UPDATE REQUEST message, the 
previously initiated tracking area updating procedure shall be aborted if the TRACKING AREA UPDATE 
COMPLETE message has not been received and the new tracking area updating procedure shall be 
progressed; or 

- if the information elements do not differ, then the TRACKING AREA UPDATE ACCEPT message shall be 
resent and the timer T3450 shall be restarted if an TRACKING AREA UPDATE COMPLETE message is 
expected. In that case, the retransmission counter related to T3450 is not incremented. 

e) More than one TRACKING AREA UPDATE REQUEST received and no TRACKING AREA UPDATE 
ACCEPT or TRACKING AREA UPDATE REJECT message has been sent 

- If one or more of the information elements in the TRACKING AREA UPDATE REQUEST message differs 
from the ones received within the previous TRACKING AREA UPDATE REQUEST message, the 
previously initiated tracking area updating procedure shall be aborted and the new tracking area updating 
procedure shall be progressed; 

- if the information elements do not differ, then the network shall continue with the previous tracking area 
updating procedure and shall not treat any further this TRACKING AREA UPDATE REQUEST message. 

f) Lower layers indication of non-delivered NAS PDU due to handover 

If the TRACKING AREA UPDATE ACCEPT message or TRACKING AREA UPDATE REJECT message 
could not be delivered due to handover then the MME shall retransmit the TRACKING AREA UPDATE 
ACCEPT message or TRACKING AREA UPDATE REJECT message if the failure of handover procedure 
is reported by the lower layer and the SI signalling connection exists. 



Within a combined tracking area updating procedure the messages TRACKING AREA UPDATE ACCEPT and 
TRACKING AREA UPDATE COMPLETE carry information for the tracking area updating and the location area 
updating. 

The combined tracking area updating procedure follows the normal tracking area updating procedure described in 
subclause 5.5.3.2. 

5.5.3.3.2 Combined tracking area updating procedure initiation 

The UE operating in CS/PS mode 1 or CS/PS mode 2, in state EMM-REGISTERED, shall initiate the combined 
tracking area updating procedure: 

a) when the UE that is attached for both EPS and non-EPS services detects entering a tracking area that is not in the 
list of tracking areas that the UE previously registered in the MME; 

b) when the UE that is attached for EPS services wants to perform an attach for non-EPS services. In this case the 
EPS update type IE shall be set to "Combined TA/LA updating with IMSI attach"; 

c) when the UE performs an intersystem change from A/Gb mode to S 1 mode and the EPS services were 
previously suspended in A/Gb mode; 

d) when the UE performs an intersystem change from A/Gb or lu mode to SI mode and the UE previously 
performed a location area update procedure in A/Gb or lu mode, in order to re-establish the SGs association; 



5.5.3.3 



Combined tracking area updating procedure 



5.5.3.3.1 



General 
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e) when the UE enters EMM-REGISTERED. NORMAL-SERVICE and the UE's TIN indicates "P-TMSI" ; 

f) when the UE receives an indication from the lower layers that the RRC connection was released with cause "load 
balancing TAU required"; 

g) when the UE deactivated EPS bearer context(s) locally while in EMM-REGISTERED.NO-CELL- 
AVAILABLE, and then returns to EMM-REGISTERED.NORMAL-SERVICE; 

h) when the UE changes the UE network capability information or the MS network capability information or both; 

i) when the UE changes the UE specific DRX parameter; 

j) when the UE receives an indication of "RRC Connection failure" from the lower layers and has no user uphnk 

data pending; or 

k) when the UE has selected a CSG cell whose CSG identity is not included in the UE's Allowed CSG list. 

To initiate a combined tracking area updating procedure the UE sends the message TRACKING AREA UPDATE 
REQUEST to the network, starts timer T3430 and changes to state EMM-TRACKING- AREA-UPDATING- 
INITIATED. The value of the EPS update type IE in the message shall indicate "combined TA/LA updating" unless 
explicitly specified otherwise. 

The UE shall include the TMSl status IE if no valid TMSl is available. Furthermore, if the UE has stored a valid 
location area identification, the UE shall include it in the Old location area identification IE in the TRACKING AREA 
UPDATE REQUEST message. 

5.5.3.3.3 EMM common procedure initiation 

The network may initiate EMM common procedures, e.g. the EMM authentication and security mode control 
procedures. 

5.5.3.3.4 Combined tracking area updating procedure accepted by tine network 

5.5.3.3.4.1 General 

Depending on the value of the EPS update result IE received in the TRACKING AREA UPDATE ACCEPT message, 
two different cases can be distinguished: 

1) The EPS update result IE value indicates "combined TA/LA updated": Tracking and location area updating is 
successful; 

2) The EPS update result IE value indicates "TA updated": Tracking area updating is successful, but location area 
updating is not successful. 

A TRACKING AREA UPDATE COMPLETE message shall be returned to the network if the TRACKING AREA 
UPDATE ACCEPT message contains a GUTl or a mobile identity or both. 

5.5.3.3.4.2 Combined tracking area updating successful 

The description for normal tracking area update as specified in subclause 5.5.3.2.4 shall be followed. In addition, the 
following description for location area updating applies. 

The TMSl reallocation may be part of the combined tracking area updating procedure. The TMSl allocated is then 
included in the TRACKING AREA UPDATE ACCEPT message together with the location area identification (LAI). In 
this case the MME shall change to state EMM-COMMON-PROCEDURE-INITIATED and shall start the timer T3450 
as described in subclause 5.4.1. The LAI may be included in the TRACKING AREA UPDATE ACCEPT message 
without TMSL 

The UE, receiving a TRACKING AREA UPDATE ACCEPT message, stores the received location area identification, 
resets the location update attempt counter, sets the update status to Ul UPDATED and enters MM state MM IDLE. 

If the LAI contained in the TRACKING AREA UPDATE ACCEPT message is a member of the list of "forbidden 
location areas for regional provision of service" or the list of "forbidden location areas for roaming" then such entry 
shall be deleted. 
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How to handle the old TMSI stored in the UE depends on the mobile identity included in the TRACKING AREA 
UPDATE ACCEPT message. 

- If the TRACKING AREA UPDATE ACCEPT message contains an IMSI, the UE is not allocated any TMSI, 
and shall delete any old TMSI accordingly. 

- If the TRACKING AREA UPDATE ACCEPT message contains a TMSI, the UE shall use this TMSI as new 
temporary identity. The UE shall delete its old TMSI and shall store the new TMSI. In this case, a TRACKING 
AREA UPDATE COMPLETE message is returned to the network to confirm the received TMSI. 

- If neither a TMSI nor an IMSI has been included by the network in the TRACKING AREA UPDATE ACCEPT 

message, the old TMSI, if any is available, shall be kept. 

The network receiving a TRACKING AREA UPDATE COMPLETE message stops timer T3450, changes to state 
EMM-REGISTERED and considers the new TMSI as valid. 

5.5.3.3.4.3 Combined tracking area updating successful for EPS services only 

Apart from the actions on the tracking area updating attempt counter, the description for tracking area for EPS services 
as specified in subclause 5.5.3.2.4 shall be followed. In addition, the following description for location updating for 
non-EPS services applies. 

The UE receiving the TRACKING AREA UPDATE ACCEPT message takes one of the following actions depending 
on the EMM cause value: 

#2 (IMSI unknown in HSS) 

The UE shall stop T3430 if still running and shall reset the tracking area updating attempt counter. The UE 
shall set the update status to U3 ROAMING NOT ALLOWED and shall delete any TMSI, LAI and ciphering 
key sequence number. The UE shall enter state EMM-REGISTERED.NORMAL-SERVICE. The new MM 
state is MM IDLE. The USIM shall be considered as invalid for non-EPS services until switching off or the 
UICC containing the USIM is removed. 

#16 (MSC temporarily not reachable); 

#17 (Network failure); or 

#22 (Congestion) 

The UE shall stop timer T3430 if still running. The tracking area updating attempt counter shall be 
incremented, unless it was already set to 5. 

If the tracking area updating attempt counter is less than 5: 

- the UE shall start timer T341 1, shall set the EPS update status to EUl UPDATED and shall enter state 
EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM. When timer T341 1 expires the combined 
tracking area updating procedure indicating "combined TA/LA updating with IMSI attach" is triggered 
again. 

If the tracking area updating attempt counter is equal to 5: 

- the UE shall start timer T3402, shall set the EPS update status to EUl UPDATED and shall enter state 
EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM. When timer T3402 expires the combined 
tracking area updating procedure indicating "combined TA/LA updating with IMSI attach" is triggered 
again; 

- a UE operating in CS/PS mode 1 of operation shall select GERAN or UTRAN radio access technology 
and proceed with appropriate MM or GMM specific procedures. 

NOTE 1: It is up to the UE implementation when to enable E-UTRAN radio access technology selection. 

#18 (CS domain not available) 

The UE shall stop timer T3430 if still running, shall reset the tracking area updating attempt counter, shall set 
the EPS update status to EUl UPDATED and shall enter state EMM-REGISTERED.NORMAL-SERVICE. 
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The UE shall set the update status to U2 NOT UPDATED. 

A UE in CS/PS mode 1 of operation shall preferably select GERAN or UTRAN radio access technology 
rather than E-UTRAN for the selected PLMN or equivalent PLMN. 

NOTE 2: Some interaction is required with the access stratum layer(s) to give the lowest priority (as defined in 
3GPP TS 25.304 [15A], 3GPP TS 36.304 [21] and 3GPP TS 45.008 [23A]) to E-UTRAN. The NAS 
indicated priority takes precedence over any priority information already stored in the access stratum 
layer(s) and is valid until PLMN selection (as defined in 3GPP TS 23.122 [6]) is performed. 

The UE shall not attempt combined attach or combined tracking area updating procedure with current PLMN 
until switching off the UE or the UlCC containing the USIM is removed. 

Other EMM cause values and the case that no EMM cause IE was received are considered as abnormal cases. The 
combined tracking area updating procedure shall be considered as failed for EPS and non-EPS services. The behaviour 
of the UE in those cases is specified in subclause 5.5.3.3.6. 

5.5.3.3.5 Combined tracking area updating procedure not accepted by the network 

If the combined tracking area updating cannot be accepted by the network, the MME shall send a TRACKING AREA 
UPDATE REJECT message to the UE including an appropriate EMM cause value. 

Upon receiving the TRACKING AREA UPDATE REJECT message, the UE shall stop timer T3430, stop any 
transmission of user data, enter state MM IDLE, and take the following actions depending on the EMM cause value 
received. 

#3 (Illegal UE); 

#6 (Illegal ME); or 

#8 (EPS services and non-EPS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI Listand KSI. 

The UE shall consider the USIM as invalid for EPS and non-EPS services until switching off or the UICC 
containing the USIM is removed. Additionally, the UE shall delete the list of equivalent PLMNs and shall enter 
the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the MM parameters update status, TMSI, 
LAI and ciphering key sequence number, and the GMM parameters GMM state, GPRS update status, P-TMSI, 
P-TMSI signature, RAI and GPRS ciphering key sequence number as specified in 3GPP TS 24.008 [13] for the 
case when the combined routing area updating procedure is rejected with the GMM cause with the same value. 

#7 (EPS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI List and KSI. The UE shall 
consider then USIM as invalid for EPS services until switching off or the UICC containing the USIM is 
removed. The UE shall delete the list of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

Editor's note: The handling of timer T3212 for non-EPS service is EES. 

A UE in CS/PS mode 1 or CS/PS mode 2 of operation is still IMSI attached for non-EPS services. The UE shall 
select GERAN or UTRAN radio access technology and proceed with appropriate MM specific procedure 
according to the MM service state. The UE shall not reselect E-UTRAN radio access technology until switching 
off or the UICC containing the USIM is removed. 

NOTE: Some interaction is required with the access stratum to disable E-UTRAN cell reselection. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as 
specified in 3GPP TS 24.008 [13] for the case when the combined routing area updating procedure is rejected 
with the GMM cause with the same value. 
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#9 (UE identity cannot be derived by the network); 

The UE shall set the EPS update status to EU2 NOT UPDATED (and shall store it according to 

subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI List and KSI. The UE shall delete 

the list of equivalent PLMNs and enter the state EMM-DEREGISTERED. 

Subsequently, the UE shall automatically initiate the attach procedure. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as 
specified in 3GPP TS 24.008 [13] for the case when the combined routing area updating procedure is rejected 

with the GMM cause with the same value. 

A UE in CS/PS mode 1 or CS/PS mode 2 of operation is still IMSI attached for non-EPS services. 

# 1 (Implicitly detached) ; 

The UE shall delete the hst of equivalent PLMNs and shall enter the state EMM-DEREGISTERED.NORMAL- 
SERVICE. The UE shall delete the mapped EPS security context if any. The UE shall then perform a new attach 
procedure. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM state as specified in 
3GPP TS 24.008 1 1 3 1 for the case when the combined routing area updating procedure is rejected with the GMM 
cause with the same value. 

A UE in CS/PS mode 1 or CS/PS mode 2 of operation is still IMSI attached for non-EPS services. 

#11 (PLMN not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI List and KSI, and reset the 
tracking area updating attempt counter. The UE shall delete the list of equivalent PLMNs and enter the state 
EMM-DEREGISTERED.PLMN-SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMN list". 

The UE shall then perform a PLMN selection according to 3GPP TS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle and the MM parameters update status, 
TMSI, LAI, ciphering key sequence number and the location update attempt counter, and the GMM parameters 
GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence number and 
routing area updating attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined 
routing area updating procedure is rejected with the GMM cause with the same value and no RR connection 
exists. 

#12 (Tracking area not allowed) ; 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI List and KSI. The UE shall reset 
the tracking area updating attempt counter and shall enter the state EMM-DEREGISTERED .LIMITED- 
SERVICE. 

The UE shall store the current TAI in the list of "forbidden tracking areas for regional provision of service". 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the MM parameters update status, TMSI, 
LAI, ciphering key sequence number and the location update attempt counter, and the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence number and routing 
area updating attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined routing area 
updating procedure is rejected with the GMM cause with the same value. 

#13 (Roaming not allowed in this tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete the list of equivalent PLMNs. The UE shall reset the tracking area updating 
attempt counter and shall change to state EMM-REGISTERED .PLMN-SEARCH. 
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The UE shall store the current TAI in the list of "forbidden tracking areas for roaming" and shall remove the 
current TAI from the stored TAI list if present. 

The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6]. 

The UE shall indicate the Update type IE "combined TA/LA updating with IMSI attach" when performing the 
tracking area updating procedure following the PLMN selection. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the MM parameters update status and the 
location update attempt counter, and the GMM parameters GMM state, GPRS update status and routing area 
updating attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined routing area 
updating procedure is rejected with the GMM cause with the same value. 

#14 (EPS services not allowed in this PLMN); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). Furthermodre the UE shall delete any GUTI, last visited registered TAI, TAI List and KSI. 
The UE shall reset the tracking area updating attempt counter and shall enter the state EMM- 
DEREGISTERED.PLMN-SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMNs for GPRS service" list. 

A UE operating in CS/PS mode 1 or CS/PS mode 2 of operation is still IMSI attached for non-EPS services. If 
the timer T3212 is not already running in the UE, the UE shall set the timer T3212 to its initial value and restart 
it. 

A UE operating in CS/PS mode 1 of operation may select GERAN or UTRAN radio access technology and 
proceed with the appropriate MM specific procedure according to the MM service state. In this case the UE shall 
not reselect E-UTRAN radio access technology for the duration the UE is on the PLMN or equivalent PLMN. 

A UE in CS/PS mode 1 of operation may perform a PLMN selection according to 3GPP TS 23. 122 [6]. 

A UE operating in CS/PS mode 2 of operation shall perform a PLMN selection according to 
3GPP TS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence number and routing area updating 
attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined routing area updating 
procedure is rejected with the GMM cause with the same value. 

#15 (No suitable cells in tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). The UE shall reset the tracking area updating attempt counter and shall enter the state EMM- 
REGISTERED.LIMITED-SERVICE. 

The UE shall store the current TAI in the list of "forbidden tracking areas for roaming" and shall remove the 
current TAI from the stored TAI Ust if present. 

The UE shall search for a suitable cell in another tracking area or in another location area in the same PLMN 
according to 3GPP TS 36.304 [21]. 

The UE shall indicate the Update type IE "combined TA/LA updating with IMSI attach" when performing the 

tracking area updating procedure. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the MM parameters update status and the 
location update attempt counter, and the GMM parameters GMM state, GPRS update status and routing area 
updating attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined routing area 
updating procedure is rejected with the GMM cause with the same value. 

#25 (Not authorized for this CSG); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). The UE shall reset the tracking area updating attempt counter and shall enter the state EMM- 
REGISTERED.LIMITED-SERVICE. 
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The UE shall remove the CSG ID of the cell where the UE has sent the TRACKING AREA UPDATE 
REQUEST message if the CSG ID is contained in the Allowed CSG list. 

The UE shall search for a suitable cell in the same PLMN according to 3GPP TS 36.304 [21]. 

The UE shall indicate the Update type IE "combined TA/LA updating with IMSI attach" when perfornaing the 
tracking area updating procedure. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the MM parameters update status and the 
location update attempt counter, and the GMM parameters GMM state, GPRS update status and routing area 
updating attempt counter as specified in 3GPP TS 24.008 [13] for the case when the combined routing area 
updating procedure is rejected with the GMM cause with the same value. 

Other values are considered as abnormal cases. The behaviour of the UE in those cases is specified in 
subclause 5.5.3.3.6. 

5.5.3.3.6 Abnormal cases in the UE 

The UE shall proceed as follows: 

if the combined tracking area update was successful for EPS services only and the TRACKING AREA 
UPDATE ACCEPT message contained an EMM cause value not treated in subclause 5.5.3.3.4.3 or the EMM 
Cause IE is not included in the message, the UE shall follow the procedure specified in subclause 5.5.3.2.6, 
item d with the following modification; 

- otherwise, the abnormal cases specified in subclause 5.5.3.2.6 apply with the following modification. 

If the tracking area updating attempt counter is incremented according to subclause 5.5.3.2.6 the next actions depend on 
the value of the tracking area updating attempt counter. 

if the update status is Ul UPDATED and the tracking area updating attempt counter is less than 5, then the UE 
shall keep the update status to Ul UPDATED, the new MM state is MM IDLE substate NORMAL SERVICE; 

if the tracking area updating attempt counter is less than 5 and, additionally, the update status is different from 
Ul UPDATED UE shall delete any LAI, TMSI, ciphering key sequence number and list of equivalent PLMNs 
and set the update status to U2 NOT UPDATED. The MM state remains MM LOCATION UPDATING 
PENDING; or 

if the tracking area updating attempt counter is equal to 5, the UE shall delete any LAI, TMSI, ciphering key 
sequence number and list of equivalent PLMNs and set the update status to U2 NOT UPDATED. A UE 
operating in CS/PS mode 1 of operation shall select GERAN or UTRAN radio access technology and proceed 
with appropriate MM or GMM specific procedures. 

NOTE: It is up to the UE implementation when to enable E-UTRAN radio access technology selection. 

5.5.3.3.7 Abnormal cases on the network side 

The abnormal cases specified in subclause 5.5.3.2.7 apply with the exceptions for cases a and c in which in addition to 
the GUTI the old TMSI shall be considered occupied until the new TMSI is used by the UE in a subsequent message. 

5.6 EMM connection management procedures (S1 mode only) 

5.6.1 Service request procedure 

5.6.1.1 General 

The purpose of the service request procedure is to transfer the EMM mode from EMM-IDLE to EMM-CONNECTED 
mode and establish the radio and SI bearers when uplink user data or signalUng is to be sent. Another piupose of this 
procedure is to invoke MO/MT CS fallback procedures. 

This procedure is used when: 
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- the network has downlink signalling pending; 

- the UE has uplink signalling pending; 

- the UE or the network has user data pending and the UE is in EMM-IDLE mode; 

- the UE in EMM-IDLE or EMM-CONNECTED mode has requested to perform mobile originating/terminating 
CS fallback; 

- the network has downlink cdma2000® signalUng pending; or 

- the UE has uplink cdma2000® signalUng pending. 

The service request procedure is initiated by the UE, however, for the downlink transfer of signalling, cdma2000® 
signalling or user data in EMM-IDLE mode, the trigger is given by the network by means of the paging procedure (see 
subclause 5.6.2). 

The UE shall invoke the service request procedure when: 

a) the UE in EMM -IDLE mode receives a paging request with CN domain indicator set to "PS" from the network; 

b) the UE, in EMM-IDLE mode, has pending user data to be sent; 

c) the UE, in EMM-IDLE mode, has uplink signalling pending; 

d) the CS fallback UE, in EMM-IDLE or EMM-CONNECTED mode, has a mobile originating CS fallback request 
from the upper layer; 

e) the CS fallback UE in EMM -IDLE mode receives a paging request with CN domain indicator set to "CS", or the 
CS fallback UE in EMM-CONNECTED mode receives a CS SERVICE NOTIFICATION message; 

f) the IxCS fallback UE, in EMM-IDLE or EMM-CONNECTED mode, has a mobile originating IxCS fallback 

request from the upper layer; 

g) the IxCS fallback UE, in EMM-CONNECTED mode accepts cdma2000® signalUng messages containing a 
IxCS paging request; or 

h) the UE, in EMM-IDLE mode, has upUnk cdma2000® signalling pending. 
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UE AS MME 

SERVICE REQUEST 
Start T3417 ► 



AS indication about 
data radio bearer establishment 



Stop T3417 



Start T3417ext 



Stop T3417ext 



OR 

EXTENDED SERVICE REQUEST 

AS indication about system 
change 



OR 

Start T34 1 7 SERVICE REQUEST 



SERVICE REJECT 

Stop T34 1 7 M 



Start T3417ext 



OR 

EXTENDED SERVICE REQUEST 



SERVICE REJECT 

StopT3417ext 



NOTE: AS indications (indications from lower layers) are results of procedures triggered by IVIME in Service 

Request procedure. Triggered procedures could be e.g. RRC Connection Reconfiguration procedure (see 
3GPP TS 36.331 [22]) and inter system PS handover to GERAN or UTRAN procedure as a result of CSFB 
procedure (see 3GPP TS 23.272 [9]). 

Figure 5.6.1.1.1: Service Request procedure 
5.6.1 .2 Service request procedure initiation 

If the UE has pending uphnk data or uplink signalhng in EMM-IDLE mode to be transmitted or it responds to paging 
with CN domain indicator set to "PS", the UE initiates the service request procedure by sending a SERVICE REQUEST 
message to the MME, starts the timer T34I7, and enters the state EMM-SERVICE-REQUEST-INITIATED. 

For case d in subclause 5.6.1.1, the UE shall send an EXTENDED SERVICE REQUEST message, start T3417ext and 
enter the state EMM-SERVICE-REQUEST-INTriATED. 

For case e in subclause 5.6.1.1: 



- if the UE is in EMM-IDLE mode, the UE shall send an EXTENDED SERVICE REQUEST message, start 
T3417ext and enter the state EMM-SERVICE-REQUEST-INITIATED; 

- if the UE is in EMM-CONNECTED mode and if the UE accepts the paging, the UE shall send an EXTENDED 
SERVICE REQUEST message with the CSFB response IE indicating "CS fallback accepted by the UE", start 
T3417ext and enter the state EMM-SERVICE-REQUEST-INITIATED; or 
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- if the UE is in EMM-CONNECTED mode and if the UE rejects the paging, the UE shall send an EXTENDED 
SERVICE REQUEST message with the CSFB response IE indicating "CS fallback rejected by the UE" and 
enter the state EMM-REGISTERED .NORMAL-SERVICE. The network shall not initiate CS fallback 
procedures. 

For cases f and g in subclause 5.6.1.1, the UE shall send an EXTENDED SERVICE REQUEST message, start T3417 
and enter the state EMM-SERVICE-REQUEST-INITIATED. 

5.6.1 .3 EMM common procedure initiation 

Upon receipt of the SERVICE REQUEST or EXTENDED SERVICE REQUEST message, the MME may initiate the 
EMM connmon procedures e.g. the authentication procedure and security mode control procedure. 

5.6.1 .4 Service request procedure accepted by the network 

For cases a, b, c and h in subclause 5. 6. 1. 1, the UE shall treat the indication from the lower layers that the user plane 
radio bearer is set up as successful completion of the procedure. The UE shall stop the timer T3417 and enter the state 
EMM-REGISTERED. 

If the service type information element in the EXTENDED SERVICE REQUEST message indicates "mobile 
terminating CS fallback or IxCS fallback" and the CSFB response IE indicates "CS fallback accepted by the UE", or if 
the service type information element in the EXTENDED SERVICE REQUEST message indicates "mobile originating 
CS fallback or IxCS fallback", the network initiates CS fallback procedures. 

For cases d in subclause 5.6.1.1, and for case e in subclause 5.6.1.1 when the CSFB response was set to "CS fallback 
accepted by the UE", the UE shall treat the indication from the lower layers that the inter-system change from SI mode 
to A/Gb or lu mode is completed as successful completion of the procedure.The EMM sublayer in the UE shall indicate 
to the MM sublayer that the CS fallback procedure has succeeded. The UE shall stop the timer T3417ext and enter the 
state EMM-REGISTERED.NO-CELL-AVAILABLE. 

For cases f and g in subclause 5.6.1.1, the UE shall treat the indication from the lower layers that the signalling 
connection is released with the redirection indication to cdma2000® Ix access network as successful completion of the 
procedure. The UE shall stop the timer T3417 and enter the state EMM-REGISTERED .NO-CELL-AVAILABLE. 

The UE shall locally deactivate the EPS bearer contexts that do not have a user plane radio bearer established after the 
successful completion of the service request procedure. 

When the E-UTRAN fails to establish radio bearers for one or more EPS bearer contexts, then the MME shall locally 
deactivate the EPS bearer contexts corresponding to the failed radio bearers based on the lower layer indication from 
the E-UTRAN, without notifying the UE. 

5.6.1 .5 Service request procedure not accepted by tine network 

If the service request cannot be accepted, the network shall return a SERVICE REJECT message to the UE including an 
appropriate EMM cause value. When the EMM cause value is #39 "CS domain temporarily not available", the MME 
shall include a value for timer T3442 in the SERVICE REJECT message. 

On receipt of the SERVICE REJECT message, the UE shall stop timer T3417 and take the following actions depending 
on the received EMM cause value. 

#3 (Illegal UE); or 

#6 (Illegal ME); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall 
consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
The UE shall enter the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number and the MM 
parameters update status, TMSI, LAI and ciphering key sequence number as specified in 3GPP TS 24.008 [13] 
for the case when the service request procedure is rejected with the GMM cause with the same value. The USIM 
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shall be considered as invalid also for non-EPS services until switching off or the UICC containing the USIM is 

removed. 

NOTE 1: The possibihty to configure a UE so that the radio transceiver for a specific radio access technology is not 
active, although it is implemented in the UE, is out of scope of the present specification. 

#7 (EPS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.L3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall 
consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 

The UE shall enter the state EMM-DEREGISTERED. 

A UE operating in CS/PS mode 1 or CS/PS mode 2 of operation is still IMSI attached for non-EPS services. The 
UE shall select GERAN or UTRAN radio access technology and proceed with appropriate MM specific 
procedure according to the MM service state. The UE shall not reselect E-UTRAN radio access technology until 
switching off or the UICC containing the USIM is removed. 

NOTE 2: Some interaction is required with the access stratum to disable E-UTRAN cell reselection. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as specified in 
3GPP TS 24.008 [13] for the case when the service request procedure is rejected with the GMM cause with the 
same value. 

#9 (UE identity cannot be derived by the network); 

The UE shall set the EPS update status to EU2 NOT UPDATED (and shall store it according to 

subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI hst and KSI. The UE shall enter 

the state EMM-DEREGISTERED. 

Subsequently, the UE shall automatically initiate the attach procedure. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as specified in 
3GPP TS 24.008 [13] for the case when the service request procedure is rejected with the GMM cause with the 

same value. 

A UE operating in CS/PS mode 1 or CS/PS mode 2 of operation is still IMSI attached for non-EPS services. 

# 1 (Implicitly detached) ; 

The UE shall enter the state EMM-DEREGISTERED.NORMAL-SERVICE. The UE shall delete the EPS 
mapped EPS security context if any. The UE shall then perform a new attach procedure. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM state as specified in 

3GPP TS 24.008 [13] for the case when the service request procedure is rejected with the GMM cause with the 

same value. 

A UE operating in CS/PS mode 1 or CS/PS mode 2 of operation is still IMSI attached for non-EPS services. 

#11 (PLMN not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI Ust and KSI. The UE shall enter 
the state EMM-DEREGISTERED.PLMN-SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMN list". 

The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number and the MM 
parameters update status, TMSI, LAI, ciphering key sequence number and the location update attempt counter as 
specified in 3GPP TS 24.008 [13] for the case when the service request procedure is rejected with the GMM 
cause with the same value. 
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#12 (Tracking area not allowed) ; 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI Ust and KSI. The UE shall enter 
the state EMM-DEREGISTERED.LIMITED-SERVICE. 

The UE shall store the current TAI in the list of "forbidden tracking areas for regional provision of service". 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS 
update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as specified in 
3GPP TS 24.008 [13] for the case when the service request procedure is rejected with the GMM cause with the 

same value. 

#13 (Roaming not allowed in this tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). The UE shall enter the state EMM-REGISTERED.PLMN-SEARCH. 

The UE shall store the current TAI in the list of "forbidden tracking areas for roaming" and remove the current 
TAI from the stored TAI list if present. 

The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state and 
GPRS update status as specified in 3GPP TS 24.008 [13] for the case when the service request procedure is 
rejected with the GMM cause with the same value. 

#15 (No suitable cells in tracking area); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). The UE shall enter the state EMM-REGISTERED.LIMITED-SERVICE. 

The UE shall store the current TAI in the list of "forbidden tracking areas for roaming" and remove the current 
TAI from the stored TAI list if present. 

The UE shall search for a suitable cell in another tracking area or in another location area in the same PLMN 
according to 3GPP TS 36.304 [21]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state and 
GPRS update status as specified in 3GPP TS 24.008 [13] for the case when the service request procedure is 
rejected with the GMM cause with the same value. 

#18 (CS domain not available); 

If the request was related to CS fallback, the UE shall send an indication to the MM sublayer and shall not 
attempt CS fallback until combined tracking area updating procedme has been successfully completed. The UE 
shall enter the state EMM-REGISTERED.NORMAL-SERVICE. 

If the request was related to IxCS fallback, the UE shall cancel upper layer actions related to CS fallback and 
enter the state EMM-REGISTERED.NORMAL-SERVICE. 

#25 (Not authorized for this CSG); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3). The UE shall enter the state EMM-REGISTERED.LIMITED-SERVICE. 

The UE shall remove the CSG ID of the cell where the UE has initiated the service request procedure from the 
Allowed CSG hst. 

The UE shaU search for a suitable ceU in the same PLMN according to 3GPP TS 36.304 [21]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall handle the GMM parameters GMM state and 
GPRS update status as specified in 3GPP TS 24.008 [13] for the case when the service request procedure is 
rejected with the GMM cause with the same value. 

#39 (CS domain temporarily not available); 
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The UE shall start timer T3442 and shall set the EPS update status to EU2 NOT UPDATED (and shall store it 
according to subclause 5.1.3.3). The UE shall enter the state EMM-REGISTERED.NORMAL-SERVICE. 

The UE shall not try to send an EXTENDED SERVICE REQUEST message for mobile originating services to 
the network until timer T3442 expires or the UE sends a TRACKING AREA UPDATE REQUEST message. 

Other values are considered as abnormal cases. The specification of the UE behaviour in those cases is described in 
subclause 5.6.1.6. 

5.6.1 .6 Abnormal cases in the UE 

The following abnormal cases can be identified: 

a) Access barred because of access class barring or NAS signalUng cormection establishment rejected by the 

network 

If the service request procedure is started in response to a paging request from the network, access class barring 
is not applicable. 

If the trigger for the service request procedure is the response to a paging request from the network and the NAS 
signalling connection establishment is rejected by the network, the service request procedure shall not be started. 
The UE stays in the current serving cell and applies normal cell reselection process. The service request 
procedure may be started if it is still necessary, i.e. when access for "terminating calls" is granted or because of a 
cell change. 

Otherwise, if access is barred for "originating calls" (see 3GPP TS 36.331 [22]), the service request procedure 
shall not be started. The UE stays in the current serving cell and applies normal cell reselection process. The 
service request procedure may be started if it is still necessary, i.e. when access for "originating calls" is granted 
or because of a cell change. 

If the service request was initiated for CS fallback, the UE shall select GERAN or UTRAN radio access 
technology. The UE then proceeds with appropriate MM and CC specific procedures. 

If the service request was initiated for IxCS fallback, the UE shall select cdma2000® Ix radio access technology. 
The UE then proceeds with appropriate cdma2000® Ix CS call processing. 

b) Lower layer failure before the NAS security mode control procedure is completed or SERVICE REJECT 

message is received 

If the service request was initiated for CS fallback, the UE shall select GERAN or UTRAN radio access 
technology. The UE then proceeds with appropriate MM and CC specific procedures. 

If the service request was initiated for IxCS fallback, the UE shall select cdma2000® Ix radio access technology. 
The UE then proceeds with appropriate cdma2000® Ix CS call processing. 

Otherwise, the UE shall enter state EMM-REGISTERED. The UE shall abort the service request procedure, stop 
timer T3417 and locally release any resources allocated for the service request procedure. 

c) T3417 expired 

The UE shall enter state EMM-REGISTERED. 

The UE shall abort the procedure and release locally any resources allocated for the service request procedure. 

d) T3417ext expired 

The EMM sublayer shall abort the procedure and indicate to the MM sublayer that the CS fallback procedure has 
failed, and then enter the state EMM-REGISTERED. 

e) SERVICE REJECT received, other EMM cause values than those treated in subclause 5.6.1.5 

The procedure shall be aborted and move to EMM-REGISTERED. If the service request was initiated for CS 
fallback, the UE shall select GERAN or UTRAN radio access technology. It then proceeds with appropriate MM 
specific procedures. If the service request was initiated for IxCS fallback, the UE shall select cdma2000® Ix 
radio access technology. The UE then proceeds with appropriate cdma2000® Ix CS call processing. 
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f) Tracking area updating procedure is triggered 

The UE shall abort the service request procedure, stop timer T3417 or T3417ext if running and perform the 
tracking area updating procedure. The "active" flag shall be set in the TRACKING AREA UPDATE REQUEST 
message. If the service request was initiated for CS fallback or IxCS fallback, the UE shall send the 
EXTENDED SERVICE REQUEST message to the MME by using the existing NAS signalUng connection after 
the completion of the tracking area updating procedure. 

g) Switch off 

If the UE is in state EMM-SERVICE-REQUEST-INITIATED at switch off, the detach procedure shall be 
performed. 

h) Procedure collision 

If the UE receives a DETACH REQUEST message from the network in state EMM-SERVICE-REQUEST- 
INl l lATED, the detach procedure shall be progressed and the service request procedure shall be aborted. 

Additionally, if the service request was initated for CS fallback or IxCS fallback, the EMM sublayer shall 
indicate to the MM sublayer or the cdma2000® upper layers that the CS fallback or IxCS fallback procedure has 
failed. 

If the Detach type IE in the DETACH REQUEST message indicated "re-attach required", the attach procedure 
shall be performed. 

i) Transmission failure of SERVICE REQUEST or EXTENDED SERVICE REQUEST message indication with 
TAI change from lower layers 

If the ciurent TAI is not in the TAI list, the service request procedure shall be aborted to perform the tracking 
area updating procedure. The "active" flag shall be set in the TRACKING AREA UPDATE REQUEST 
message. If the service request was initiated for CS fallback or IxCS fallback, the UE shall send the 
EXTENDED SERVICE REQUEST message to the MME by using the existing NAS signalhng connection after 
the completion of the tracking area updating procedure. 

If the current TAI is still part of the TAI list, the UE shall restart the service request procedure. 

j) Transmission failure of SERVICE REQUEST or EXTENDED SERVICE REQUEST message indication 
without TAI change from lower layers 

The UE shall restart the service request procedure. 

k) Default or dedicated bearer set up failure 

If the lower layers indicate a failure to set up a radio bearer, the UE shall locally deactivate the EPS bearer as 
described in subclause 6.4.4.6. 

5.6.1 .7 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) Lower layer failure 

If a lower layer failure occurs before the security mode control procedure is completed, a SERVICE REJECT 
message has been sent to the UE or the service request procedure has been accepted by the network, the network 
enters/stays in EMM-IDLE. 

b) Protocol error 

If the SERVICE REQUEST or the EXTENDED SERVICE REQUEST message is received with a protocol 
error, the network shall return a SERVICE REJECT message with one of the following EMM cause values: 

#96: invalid mandatory information; 

#99: information element non-existent or not implemented; 
#100: conditional IE error; or 
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#111: protocol error, imspecified. 

The network stays in the current EMM mode. 

c) More than one SERVICE REQUEST received and the procedure has not been completed (i.e., the security mode 
control procedure has not been completed or SERVICE REJECT message has not been sent or service request 
procedure has not been completed) 

If one or more of the information elements in the SERVICE REQUEST message differs from the ones 
received within the previous SERVICE REQUEST message, the previously initiated service request 
procedure shall be aborted and the new service request procedure shall be progressed; 

If the information elements do not differ, then the network shall continue with the previous service request 
procedure and shall not treat any further this SERVICE REQUEST message. 

d) ATTACH REQUEST received before the security mode control procedure has been completed or a SERVICE 
REJECT message has been sent or the service request procedure has been completed 

If an ATTACH REQUEST message is received and the security mode control procedure has not been completed 
or the service request procedure has not been completed or a SERVICE REJECT message has not been sent, the 
network may initiate the EMM common procedures, e.g. the EMM authentication procedure. The network may 
e.g. after a successful EMM authentication procedure execution, abort the service request procedure, delete the 
EMM context, EPS bearer contexts, if any, and progress the new ATTACH REQUEST. 

e) TRACKING AREA UPDATE REQUEST message received before the security mode control procedure has 
been completed or the service request procedure has been completed or a SERVICE REJECT message has been 
sent 

If a TRACKING AREA UPDATE REQUEST message is received and the security mode control procedure has 
not been completed or the service request procedure has not been completed or a SERVICE REJECT message 
has not been sent, the network may initiate the EMM common procedures, e.g. the EMM authentication 
procedure. The network may e.g. after a successful EMM authentication procedure execution, abort the service 
request procedure and progress the tracking area updating procedure. 

f) Default or dedicated bearer set up failure 

If the lower layers indicate a failure to set up a radio or SI bearer, the MME shall locally deactivate the EPS 
bearer as described in subclause 6.4.4.6. 

5.6.2 Paging procedure 

5.6.2.1 General 

The paging procedure is used by the network to request the establishment of a NAS signalling connection to the UE. 
The NAS signalling connection thus established can also be used to transport cdma2000® signalling messages to the 
UE. Another purpose of the paging procedure is to prompt the UE to reattach if necessary as a result of a network 
failure. If the UE is not attached when it receives a paging for EPS services, the UE shall ignore the paging. 

Additionally, the network can use the paging procedure to initiate the mobile terminating CS fallback procedure. 

5.6.2.2 Paging for EPS services 

5.6.2.2.1 Paging for EPS services tlirougli E-UTRAN using S-TMSI 

The network shall initiate the paging procedure for EPS services using S-TMSI with CN domain indicator set to "PS" 
when NAS signalling messages, cdma2000® signalling messages or user data is pending to be sent to the UE when no 
NAS signalling cormection exists. 

To initiate the procedure the EMM entity in the network requests the lower layer to start paging (see 
3GPP TS 36.300 [20], 3GPP TS 36.413 [23]) and starts the timer T3413 for this paging procedure. Upon reception of a 
paging indication, the UE shall respond to the paging with a SERVICE REQUEST message (see 3GPP TS 23.401 [10] 
and 3GPP TS 36.413 [23]). If the paging for EPS services was received during an ongoing UE initiated EMM specific 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 



101 



ETSI TS 124 301 V8.2.1 (2009-06) 



procedure or service request procedure, then the UE shall ignore the paging and the UE and the network shall proceed 
with the EMM specific procedure or the service request procedure. 

The network shall stop the timer for the paging procedure when a response is received from the UE. 
5.6.2.2.2 Paging for EPS services tlirougli E-UTRAN using IMSI 

Paging for EPS services using IMSI is an abnormal procedure used for error recovery in the network. 

The network may initiate paging for EPS services using IMSI with CN domain indicator set to "PS" if the S-TMSI is 
not available due to a network failure. 

In SI mode, to initiate the procedure the EMM entity in the network requests the lower layer to start paging. If the TAI 
list is not available due to a network failure, the network may perform the paging within all tracking areas served by the 
MME (see 3GPP TS 36.331 [22] and 3GPP TS 36.413 [231). 

When a UE receives a paging for EPS services using IMSI from the network before a UE initiated EMM specific 
procedure has been completed, then the UE shall abort the EMM specific procedure and proceed according to the 
description in this subclause. 

Upon reception of a paging for EPS services using IMSI, the UE shall locally deactivate any EPS bearer context(s) and 
locally detach from EPS. Additionally the UE shall delete the following parameters: last visited registered TAI, TAI 
list, GUTI and KSIasme- The UE shall set the EPS update status to EU2 NOT UPDATED and change the state to EMM- 
DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM state, 
GPRS update status, P-TMSI, P-TMSI signature, RAI, and GPRS ciphering key sequence number as specified in 
3GPP TS 24.008 [13] for the case when a paging for GPRS services using IMSI is received. 

After performing the local detach, the UE shall then perform an attach procedure as described in subclause 5.5.1.2. If 
the UE is operating in CS/PS mode 1 or CS/PS mode 2 of operation, then the UE shall perform a combined attach 
procedure as described in subclause 5.5.1.3. 

NOTE 1 : In some cases, user interaction can be required, thus the UE cannot activate the dedicated bearer 
context(s) automatically. 

NOTE 2: The UE does not respond to the paging except with the attach request, hence timer T3413 in the network 
is not used when paging with IMSI. 

5.6.2.3 Paging for CS fallback to A/Gb or lu mode 

The network may initiate the paging procedure for non-EPS services when the UE is IMSI attached for non-EPS 
services. 

To initiate the procedure when no NAS signalling connection exists, the EMM entity in the network requests the lower 
layer to start paging (see 3GPP TS 36.300 [20], 3GPP TS 36.413 [23]). The paging message includes a CN domain 
indicator set to "CS" in order to indicate that this is paging for CS fallback. 

NOTE: The timer T3413 is not started in the network when the paging procedure is initiated for CS fallback. 

To notify the UE about an incoming mobile terminating CS service when a NAS signalling connection exists, the EMM 
entity in the network shall send a CS SERVICE NOTIFICATION message. This message may also include CS service 
related parameters (e.g. Calling Line Identification, SS or LCS related parameters). 

Upon reception of a paging indication, the UE shall respond with an EXTENDED SERVICE REQUEST. If the paging 
is received in EMM -IDLE mode, the UE shall respond immediately. If the paging is received as NAS CS 
NOTIFICATION message in EMM-CONNECTED mode, the UE may request upper layers input i.e. to accept or reject 
CS fallback before responding with an EXTENDED SERVICE REQUEST. The response is indicated in the CSFB 
response information element in the EXTENDED SERVICE REQUEST message in both EMM-IDLE and EMM- 
CONNECTED modes. 
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5.6.3 Transport of NAS messages procedure 

5.6.3.1 General 

The purpose of the transport of NAS messages procedure is to carry SMS messages in an encapsulated form between 
the MME and the UE. The procedure may be initiated by the UE or the network and can only be used when the UE is 
attached for EPS services and IMSI attached for non-EPS services and is in EMM-CONNECTED mode. 

5.6.3.2 UE initiated transport of NAS messages 

Upon request from the SMS entity to send an SMS message, the EMM entity in the UE initiates the procedure by 
sending an UPLINK NAS TRANSPORT message including the SMS message in the NAS message container IE. 

5.6.3.3 Network initiated transport of NAS messages 

The network initiates the procedure by sending a DOWNLINK NAS TRANSPORT message. When receiving the 
DOWNLINK NAS TRANSPORT message, the EMM entity in the UE shall forward the contents of the NAS message 
container IE to the SMS entity. 

5.7 Reception of an EMM STATUS message by an EMM entity 

The purpose of the sending of the EMM STATUS message is to report at any time certain error conditions detected 
upon receipt of EMM protocol data. The EMM STATUS message can be sent by both the MME and the UE (see 
example in figure 5.7.1). 

On receipt of an EMM STATUS message no state transition and no specific action shall be taken as seen from the radio 
interface, i.e. local actions are possible. The local actions to be taken by the MME or the UE on receipt of an EMM 
STATUS message are implementation dependent. 

UE MME 

EMM STATUS 

-M 

OR 

EMM STATUS 

► 

Figure 5.7.1 : EMM status procedure 



6 Elementary procedures for EPS session 
management 

6.1 Overview 
6.1.1 General 

This clause describes the procediu^es used for EPS session management (ESM) at the radio interface (reference point 
"LTE-Uu"). 

The main function of the ESM sublayer is to support the EPS bearer context handling in the UE and in the MME. 
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The ESM comprises procedures for: 

- the activation, deactivation and modification of EPS bearer contexts; and 

- the request for resources (IP connectivity to a PDN or dedicated bearer resources) by the UE. 

Each EPS bearer context represents an EPS bearer between the UE and a PDN. EPS bearer contexts can remain 
activated even if the radio and SI bearers constituting the corresponding EPS bearers between UE and MME are 

temporarily released. 

An EPS bearer context can be either a default bearer context or a dedicated bearer context. 
A default EPS bearer context is activated when the UE requests a connection to a PDN. 

Generally, ESM procedures can be performed only if an EMM context has been established between the UE and the 
MME, and the secure exchange of NAS messages has been initiated by the MME by use of the EMM procedures 
described in clause 5. The first default EPS bearer context, however, is activated during the EPS attach procedure (see 
subclause 4.2). Once the UE is successfully attached, the UE can request the MME to set up connections to additional 
PDNs. For each additional connection, the MME will activate a separate default EPS bearer context. A default EPS 
bearer context remains activated throughout the lifetime of the connection to the PDN. 

A dedicated EPS bearer context is always linked to a default EPS bearer context and represents additional EPS bearer 
resources between the UE and the PDN. The network can initiate the activation of dedicated EPS bearer contexts 
together with the activation of the default EPS bearer context or at any time later, as long as the default EPS bearer 
context remains activated. 

Default and dedicated EPS bearer contexts can be modified. Dedicated EPS bearer contexts can be released without 
affecting the default EPS bearer context. When the default EPS bearer context is released, then all dedicated EPS bearer 
contexts linked to it are released, too. 

The UE can request the network to allocate, modify or release additional EPS bearer resources. The network decides 
whether to fulfil a request for additional resources by activating a new dedicated EPS bearer context or modifying an 
existing dedicated or default EPS bearer context. 

6.1 .2 Types of ESM procedures 

Two types of ESM procedures can be distinguished: 

1) Procedures related to EPS bearer contexts: 

These procedures are initiated by the network and are used for the manipulation of EPS bearer contexts: 

- default EPS bearer context activation; 
dedicated EPS bearer context activation; 
EPS bearer context modification; 

- EPS bearer context deactivation. 

2) Transaction related procedures: 

These procedures are initiated by the UE to request for resources, i.e. a new PDN connection or dedicated bearer 
resources, or to release these resources: 

- PDN connectivity procedure; 

- PDN disconnect procedure; 

- bearer resource allocation procedure; 

- bearer resource modification procedure. 

When combined with the attach procedure, the PDN connectivity procedure can trigger the network to execute 
the following transaction related procedure: 
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- ESM information request procedure. 

A successful transaction related procedure initiated by the UE triggers the network to execute one of the procedures 
related to EPS bearer contexts. The UE treats the start of the procedure related to the EPS bearer context as completion 
of the transaction related procedure. 

6.1 .3 ESM sublayer states 

6.1.3.1 General 

In this subclause the possible states of EPS bearer contexts in the UE and on the network side are described. Each EPS 
bearer context is associated with an individual state. 

6.1 .3.2 ESM sublayer states in the UE 

6.1 .3.2.1 BEARER CONTEXT INACTIVE 

No EPS bearer context exists. 

6.1 .3.2.2 BEARER CONTEXT ACTIVE 

The EPS bearer context is active in the UE. 



ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT ppfg DISCONNECT REJECT 




ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT 
or 

ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT 

Figure 6.1.3.2.2.1 : The ESM sublayer states for EPS bearer context handling in the UE (overview) 

6.1 .3.2.3 PROCEDURE TRANSACTION INACTIVE 

No procedure transaction exists. 

6.1 .3.2.4 PROCEDURE TRANSACTION PENDING 

The UE has initiated a procedure transaction towards the network. 




UE initiated ESM procedure reject by networl< 
Or 

Networl< initiated ESIVI procedure 



Figure 6.1.3.2.4.1 : The procedure transaction states in the UE (overview) 
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6.1 .3.3 ESM sublayer states in the MME 

6.1 .3.3.1 BEARER CONTEXT INACTIVE 

No EPS bearer context exists. 

6.1 .3.3.2 BEARER CONTEXT ACTIVE PENDING 

The network has initiated an EPS bearer context activation towards the UE. 

6.1 .3.3.3 BEARER CONTEXT ACTIVE 

The EPS bearer context is active in the network. 

6.1 .3.3.4 BEARER CONTEXT INACTIVE PENDING 

The network has initiated an EPS bearer context deactivation towards the UE. 

6.1 .3.3.5 BEARER CONTEXT MODIFY PENDING 

The network has initiated an EPS bearer context modification towards the UE. 




Figure 6.1.3.3.5.1 : The ESM sublayer states for EPS bearer context handling in the network 

(overview) 



6.1 .3.3.6 PROCEDURE TRANSACTION INACTIVE 

No procedure transaction exists. 

6.1 .3.3.7 PROCEDURE TRANSACTION PENDING 

The network has initiated a procedure transaction towards the UE. 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 



106 



ETSI TS 124 301 V8.2.1 (2009-06) 




ESM procedure response by the UE 



Figure 6.1.3.3.7.1 : The procedure transaction states in tlie networic (overview) 

6.1 .4 Coordination between ESM and SM 

This section applies for a UE supporting A/Gb mode or lu mode, and SI mode. 

For inter-system change from SI mode to A/Gb mode or lu mode, SM uses the following parameters from each active 
EPS bearer context: EPS bearer identity to map to NSAPI, linked EPS bearer identity (if available) to map to linked 
NSAPl, PDN address, APN, TFT (if available), APN-AMBR if it is the default EPS bearer context, GERAN/UTRAN 
piirameters as provided while on E-UTRAN access, i.e. R99 QoS, LLC SAPI, radio priority, packet flow identifier, 
transaction identifier and BCM (if available). The mapping from EPS to pre-Rel-8 QoS parameters is given in 
3GPP TS 23.401 [10], annex E. 

For inter-system change from A/Gb mode or lu mode to SI mode, ESM uses the following parameters from each active 
PDP context: NSAPI to map to EPS bearer identity, Unked NSAPI (if available) to map to linked EPS bearer identity, 
PDP address, APN, TFT (if available), APN-AMBR if it is the default PDP context, and R99 QoS. The mapping from 
pre-Rel-8 to EPS QoS parameters is given in 3GPP TS 23.401 [10], annex E. 

6.1 .5 Coordination between ESIVI and ElVIIVI for supporting ISR 

This subclause appUes to a UE with its TIN set as "RAT-related TMSI" for which ISR is activated. 

The UE shall change its TIN to "GUTl" to deactivate ISR: 

upon modification of any EPS bearer context which was activated before the ISR is activated in the UE; or 

- at the time when the UE changes from SI mode to A/Gb mode or lu mode, if any EPS bearer context activated 
after the ISR was activated in the UE exists. 

6.2 IP address allocation 
6.2.1 General 

The UE can configure an IPv4 address during the establishment of a default EPS bearer context. The UE can obtain an 
IPv4 address or an IPv6 prefix or both via an lETF-based IP address allocation mechanism once the default bearer is 

established. 

The following lETF-based IP address/prefix allocation methods are specified for EPS (the corresponding procedures are 
specified in 3GPP TS 29.061 [16]): 

a) /64 IPv6 prefix allocation via IPv6 stateless address autoconfiguration; 

b) IPv4 address allocation and IPv4 parameter configuration via DHCPv4; 

c) IPv6 parameter configuration via stateless DHCPv6. 

NOTE: From the perspective of the UE, the procedure used to allocate a static IP address via NAS signalling is 
the same as the procedure used to allocate a dynamic IP address specified in subclause 6.2.2. 

Upon deactivation of the default bearer of a PDN connection, the UE shall locally release any IPv4 address or IPv6 
prefix allocated to the UE for the corresponding PDN connection. 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 



107 



ETSI TS 124 301 V8.2.1 (2009-06) 



6.2.2 IP address allocation via NAS signalling 

The UE shaU set the PDN type IE in the PDN CONNECTIVITY REQUEST message, based on its IP stack 
configuration as follows: 

a) - A UE, which is IPv6 and IPv4 capable and 

- has not been allocated an IP address for this APN, shall set the PDN type IE to IPv4v6. 

- has been allocated an IPv4 address for this APN and received the ESM cause #52 "single address bearers 
only allowed", and is requesting an IPv6 address, shall set the PDN type IE to IPv6. 

has been allocated an IPv6 address for this APN and received the ESM cause #52 "single address bearers 
only allowed", and is requesting an IPv4 address, shall set the PDN type IE to IPv4. 

b) A UE, which is only IPv4 capable, shall set the PDN type IE to IPv4. 

c) A UE, which is only IPv6 capable, shall set the PDN type IE to IPv6. 

d) When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are 
separated and the capability of the TE is not known in the MT), the UE shall set the PDN type IE to IPv4v6. 

If the UE wants to use DHCPv4 for IPv4 address assignment, it shall indicate that to the network within the Protocol 
Configuration Options IE in the PDN CONNECTIVITY REQUEST. 

On receipt of the PDN CONNECTIVITY REQUEST message sent by the UE, the network when allocating an IP 
address shall take into account the PDN type IE, the operator poUcies of the home and visited network, and the user's 
subscription data. 

If the UE requests for PDN type IPv4v6, but the subscription is hmited to IPv4 only or IPv6 only for the 
requested APN, the network shall override the PDN type requested by the UE to be limited to a single address 
PDN type (IPv4 or IPv6). In the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message sent to 
the UE, the network shall set the PDN type value to either "IPv4" or "IPv6" and the ESM cause value to #50 
"PDN type IPv4 only allowed", or #51 "PDN type IPv6 only allowed", respectively. The UE shall not 
subsequently initiate another UE requested PDN cormectivity procedure to the same APN to obtain a PDN type 
different from the one allowed by the network. 

If the UE requests PDN type IPv4v6, but the PDN GW configuration dictates the use of IPv4 addressing only or 
IPv6 addressing only for this APN, the network shall override the PDN type requested by the UE to limit it to a 
single address PDN type (IPv4 or IPv6). In the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST 
message sent to the UE, the network shall set the PDN type value to either "IPv4" or "IPv6" and the ESM cause 
value to #50 "PDN type IPv4 only allowed", or #51 "PDN type IPv6 only allowed", respectively. The UE shall 
not subsequently initiate another UE requested PDN connectivity procedure to the same APN to obtain a PDN 
type different from the one allowed by the network. 

If the UE requests PDN type IPv4v6, but the operator uses single addressing per bearer, e.g. due to interworking 
with nodes of earlier releases, the network shall override the PDN type requested by the UE to a single IP 
version only. In the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message sent to the UE, the 
network shall set the PDN type value to either "IPv4" or "IPv6" and the ESM cause value to #52 "single address 
bearers only allowed". The UE may subsequently request another PDN connection for the other IP version using 
the UE requested PDN connectivity procedure to the same APN with a single address PDN type (IPv4 or IPv6) 
other than the one already activated. 

If the network sets the PDN type to IPv4 or IPv4v6, the network shall include an IPv4 address in the PDN 
address information. In this case, if the IPv4 address is to be configured using DHCPv4, the network shall set the 
IPv4 address to 0.0.0.0. 

If the network sets the PDN type to IPv6 or IPv4v6, the network shall include the interface identifier that the UE 
shall use for the hnk local address in the PDN address information. 

The network shall include the PDN type and the PDN address information within the PDN address IE in the 
ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message sent to the UE. 
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6.3 General on elementary ESM procedures 

6.3.1 Services provided by lower layers 

Unless explicitly stated otherwise, the procedures described in the following subclauses can only be executed whilst a 
NAS signalUng exists between the UE and the MME. 

6.3.2 Principles of address handling for ESM procedures 

Transaction related procedures use the procedure transaction identity as address parameter in the ESM message header. 
When the UE or the network initiates a transaction related procedure, it shall include a valid procedure transaction 
identity value in the message header and set the EPS bearer identity to "no EPS bearer identity assigned". 

If the response message is again a transaction related message, e.g. a PDN CONNECTIVITY REJECT, PDN 
DISCONNECT REJECT, BEARER RESOURCE ALLOCATION REJECT, BEARER RESOURCE MODIFICATION 
REJECT or ESM INFORMATION REQUEST message from the network or an ESM INFORMATION RESPONSE 
message from the UE, the sending entity shall include the procedure transaction identity value received with the request 
message and set the EPS bearer identity to "no EPS bearer identity assigned" (see examples in figures 6.3.2.1 
and 6.3.2.2). 



UE MME 



transaction related request (PTI = a, EBI = not assigned) 



^ transaction related reject (PTI = a, EBI = not assigned) 

OR 

network intiated transaction related request 
(PTI = a, EBI = not assigned) 

Figure 6.3.2.1 : Transaction reiated procedure initiated by tlie UE and rejected by tlie network 



UE MME 

transaction related request (PTI = a, EBI = not assigned) 



transaction related response (PTI = a, EBI = not assigned) 



Figure 6.3.2.2: Transaction related procedure initiated by the networic 

EPS bearer context related procedures use the EPS bearer identity as address parameter in the ESM message header. 
When the network initiates an EPS bearer context related procedure, it shall include a valid EPS bearer identity value in 
the message header. The procedure transaction identity value shall be set as follows: 

- If the EPS bearer context related procedure was triggered by the receipt of a transaction related request message 
from the UE, the network shall include the procedure transaction identity value received with the transaction 
related request message in the message header of the EPS bearer context related request message (see example in 
figure 6.3.2.3). 

- Otherwise, if the procedure was triggered network-internally, the network shall set the procedure transaction 
identity value in the message header of the EPS bearer context related request message to "no procedure 
transaction identity assigned"(see example in figure 6.3.2.4). 
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In the response message of the EPS bearer context related procedure, the UE shall include the EPS bearer identity value 
received from the network and set the procedure transaction identity value to "no procedme transaction identity 
assigned". 

UE MME 

transaction related request (PTI = a, EBI = unassigned) ^ 
EPS bearer context related request (PTI = a, EBI = e) 



EPS bearer context related response (PTI = unassigned, EBI 
Figure 6.3.2.3: EPS bearer context related procedure triggered by a transaction related request 

UE MME 

EPS bearer context related request (PTI = unassigned, EBI = 



EPS bearer context related response (PTI = unassigned, EBI 
Figure 6.3.2.4: EPS bearer context related procedure triggered network-internally 

6.3.3 Abnormal cases in the UE 

The following abnormal case can be identified: 

a) ESM uplink message transmission failure indication by lower layers 

If lower layers indicate a TAI change, but the current TAI is not in the TAI list, the ESM procedure shall be 
aborted and re -initiated after successfully performing a tracking area updating procedure. 

If lower layers indicate a TAI change, but the current TAI is still part of the TAI list, it is up to the UE 
implementation how the ESM procedure is re-initiated. 

If lower layers indicate the TAI has not changed, it is up to the UE implementation how the ESM procedure is 
re-initiated. 

NOTE 1: The ESM procedure can typically be re-initiated using a retransmission mechanism of the uplink message 
(the one that has previously failed to be transmitted) with new sequence number and message 
authentication code information thus avoiding to restart the whole procedure. 

The case a) above does not apply to the ESM INFORMATION RESPONSE message. 

NOTE 2: The ESM INFORMATION RESPONSE message can not be subjected to a transmission failure by lower 
layers due to handover as no handover message can be accepted by the UE prior to reception of the 
ATTACH ACCEPT message (see 3GPP TS 36.331 [22]). 

b) Transmission failure of the ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message indication 
from EMM sublayer when the UE received any ACTIVATE DEDICATED EPS BEARER CONTEXT 
REQUEST messages during the attach procedure 

It is up to the UE implementation how the dedicated EPS bearer context activation procedure is re-initiated. 
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NOTE 3: The ESM procedure can typically be re -initiated using a retransmission mechanism of the ACTIVATE 
DEDICATED EPS BEARER CONTEXT ACCEPT message or ACTIVATE DEDICATED EPS 
BEARER CONTEXT REJECT message with new sequence number and message authentication code 
information thus avoiding to restart the whole procedure. 

6.3.4 Abnormal cases in the network 

The following abnormal case can be identified: 

a) Lower layer indication of non-deUvered NAS PDU due to handover 

If the downlink ESM NAS message could not be delivered due to an intra MME handover and the target TA is 
included in the TAJ list, then upon successful completion of the intra MME handover the MME shall retransmit 
the ESM message. If a failure of the handover procedure is reported by the lower layer and the SI signalling 
connection exists, the MME shall retransmit the downlink ESM NAS message. 



6.4 Network initiated ESM procedures 

6.4.1 Default EPS bearer context activation procedure 

6.4.1.1 General 

The purpose of the default bearer context activation procedure is to establish a default EPS bearer context between the 
UE and the EPC. The default EPS bearer context activation procedure is initiated by the network as a response to the 
PDN CONNECTIVITY REQUEST message from the UE. The default bearer context activation procedure can be part 
of the attach procedure, and if the attach procedure fails, the UE shall consider that the default bearer activation has 
impUcitly failed. The default EPS bearer context does not have any TFT, i.e. it uses a match-all packet filter. 

6.4.1 .2 Default EPS bearer context activation initiated by the network 

The MME shall initiate the default bearer context activation procedure by sending an ACTIVATE DEFAULT EPS 
BEARER CONTEXT REQUEST message and enter the state BEARER CONTEXT ACTIVE PENDING (see example 
in figure 6.4.1.2.1). When the default bearer is activated as part of the attach procedure, the MME shall send the 
ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message together with ATTACH ACCEPT and shall 
not start the timer T3485. When the default bearer is activated as the response to a stand-alone PDN CONNECTIVITY 
REQUEST message apart from the attach procedure, the MME shall send the ACTIVATE DEFAULT EPS BEARER 
CONTEXT REQUEST message alone, and start the timer T3485. 

The MME shall assign and include an EPS bearer identity in the ACTIVATE DEFAULT EPS BEARER CONTEXT 
REQUEST message. The MME shall retrieve the PTI from the PDN CONNECTIVITY REQUEST message and 
include it in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message. Both the network identifier 
part and the operator identifier part shall be included in the Access Point Name IE. 
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UE 



Network 



^ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST 



Start T3485 



ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT 



Stop T3485 



OR 



ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT 



Stop T3485 



Figure 6.4.1.2.1: Default EPS bearer context activation procedure 



6.4.1.3 



Default EPS bearer context activation accepted by tine UE 



Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message, the UE shall send an 
ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message and enter the state BEARER CONTEXT 
ACTIVE. When the default bearer is activated as part of the attach procedure, the UE shall send the ACTIVATE 
DEFAULT EPS BEARER CONTEXT ACCEPT message together with ATTACH COMPLETE message. When the 
default bearer is activated as the response to the stand-alone PDN CONNECTIVITY REQUEST message, the UE shall 
send the ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message alone. 

The UE checks the PTI in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message to identify the 
UE requested PDN connectivity procedure to which the default bearer context activation is related (see subclause 6.5.1). 

Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message, the MME shall enter the 
state BEARER CONTEXT ACTIVE and stop the timer T3485, if the timer is running. 

6.4.1 .4 Default EPS bearer context activation not accepted by the UE 

If the default EPS bearer context activation is part of the attach procedure, the ESM sublayer shall notify the EMM 
sublayer of an ESM failure. 

If the default EPS bearer context activation is not part of the attach procedure, the UE shall send an ACTIVATE 
DEFAULT EPS BEARER CONTEXT REJECT message and enter the state BEARER CONTEXT INACTIVE. 

The ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT message contains an ESM cause that typically 
indicates one of the following cause values: 

#26: insufficient resources; 

#3 1 : activation rej ected, imspecified; or 

#95 -111: protocol errors. 

Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT message, the MME shall enter the 
state BEARER CONTEXT INACTIVE and stop the timer T3485, if the timer is running. 



If the UE receives an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message with an EPS 
bearer identity identical to the EPS bearer identity of an already activated default EPS bearer context, the UE 



6.4.1.5 



Abnormal cases in the UE 



The following abnormal cases can be identified: 



a) Default EPS bearer context activation request for an already activated default EPS bearer context: 
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shall locally deactivate the existing default EPS bearer context and all the associated dedicated EPS bearer 
contexts, if any, and proceed with the requested default EPS bearer context activation. 

b) Default EPS bearer context activation request for an already activated dedicated EPS bearer context: 

If the UE receives an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message with an EPS 
bearer identity identical to the EPS bearer identity of an already activated dedicated EPS bearer context, the UE 
shall locally deactivate the existing dedicated EPS bearer context and proceed with the requested default EPS 
bearer context activation. 

6.4.1 .6 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) Expiry of timer T3485: 

On the first expiry of the timer T3485, the MME shaU resend the ACTIVATE DEFAULT EPS BEARER 
CONTEXT REQUEST and shall reset and restart timer T3485. This retransmission is repeated four times, i.e. on 
the fifth expiry of timer T3485, the MME shall release possibly allocated resources for this activation and shall 
abort the procedure. 

6.4.2 Dedicated EPS bearer context activation procedure 

6.4.2.1 General 

The purpose of the dedicated bearer context activation procedure is to establish an EPS bearer context with specific 
QoS and TFT between the UE and the EPC. The dedicated EPS bearer context activation procedure is initiated by the 
network, but may be requested by the UE by means of the UE requested bearer resource allocation procedure (see 
subclause 6.5.3) or the UE requested bearer resource modification procedure (see subclause 6.5.4). The dedicated bearer 
context activation procedure can be part of the attach procedure, and if the attach procedure fails, the UE shall consider 
that the dedicated bearer activation has implicitly failed. 

6.4.2.2 Dedicated EPS bearer context activation initiated by the network 

The MME shall initiate the dedicated bearer context activation procedure by sending an ACTIVATE DEDICATED 
EPS BEARER CONTEXT REQUEST message, start the timer T3485, and enter the state BEARER CONTEXT 
ACTIVE PENDING (see example in figure 6.4.2.2.1). 

The MME allocates the EPS bearer identity and includes it in the ACTIVATE DEDICATED EPS BEARER 
CONTEXT REQUEST message. The MME shall include the EPS bearer identity of the associated default bearer as the 
linked EPS bearer identity in the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message. The 
ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message shall also include a procedure transaction 
identity (PTI), if this procedure was initiated by a UE requested bearer resource allocation procedure or a UE requested 
bearer resource modification procedure. 
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UE 



Network 



ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST 



Start T3485 



ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT 



Stop T3485 



OR 



ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT 



Stop T3485 



Figure 6.4.2.2.1 : Dedicated EPS bearer context activation procedure 



6.4.2.3 



Dedicated EPS bearer context activation accepted by tine UE 



Upon receipt of the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message, the UE shall first 
check the received TFT before taking it into use. Then the UE shall send an ACTIVATE DEDICATED EPS BEARER 
CONTEXT ACCEPT message and enter the state BEARER CONTEXT ACTIVE. The ACTIVATE DEDICATED EPS 
BEARER CONTEXT ACCEPT message shall include the EPS bearer identity. 

The Unked EPS bearer identity included in the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST 
message indicates to the UE to which default bearer, IP address and PDN the dedicated bearer is linked. 

If the PTl is included in the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message, the UE uses 
the PTI to identify the UE requested bearer resource allocation procedure or the UE requested bearer resource 
modification procedure to which the dedicated bearer context activation is related. 

If the PTI is included in the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message and the PTI is 
associated to a UE requested bearer resource allocation procedure or a UE requested bearer resource modification 
procedure, the UE shall release the traffic flow aggregate description associated to the PTI value provided. 

The UE shall use the received TFT to apply mapping of uplink traffic flows to the radio bearer if the TFT contains 
packet filters for the uplink direction. 

Upon receipt of the ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT message, the MME shaU stop the 
timerT3485 and enter the state BEARER CONTEXT ACTIVE. 

6.4.2.4 Dedicated EPS bearer context activation not accepted by tine UE 

Upon receipt of the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message, the UE may reject the 
request from the MME by sending an ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT message. The 
message shall include the EPS bearer identity and an ESM cause value indicating the reason for rejecting the dedicated 
EPS bearer context activation request. 

The ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT message contains an ESM cause that typically 
indicates one of the following ESM cause values: 



#26: 


insufficient resources; 


#31: 


activation rejected, imspecified; 


#41: 


semantic error in the TFT operation; 


#42: 


syntactical error in the TFT operation; 


#43: 


invalid EPS bearer identity; 


#44: 


semantic error(s) in packet filter(s); 
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#45: syntactical error(s) in packet filter(s); 
#46: EPS bearer context without TFT already activated; or 
#95 - 111: protocol errors. 
The UE shall check the TFT in the request message for different types of TFT IE errors as follows: 

- semantic errors in the TFT operations; 

- syntactical errors in the TFT operations; 

- semantic errors in packet filters; and 

- syntactical errors in packet filters, 

as indicated in 3GPP TS 24.008 [13], subclause 6.1.3.2.3, and shall reject the request message if TFT IE errors are 
detected. 



Upon receipt of the ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT message in state BEARER 
CONTEXT ACTIVE PENDING, the MME shall stop the timer T3485, enter the state BEARER CONTEXT 
INACTIVE and abort the dedicated EPS bearer context activation procedure. The MME also requests the lower layer to 
release the radio resources that were established during the dedicated EPS bearer context activation procedure. 



The following abnormal cases can be identified: 

a) Dedicated EPS bearer context activation request for an already activated default EPS bearer context: 

If the UE receives an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message with an EPS 
bearer identity identical to the EPS bearer identity of an already activated default EPS bearer context, the UE 
shall locally deactivate the existing default EPS bearer context and all the associated dedicated EPS bearer 
contexts, if any, and proceed with the requested dedicated EPS bearer context activation. 

b) Dedicated EPS bearer context activation request for an already activated dedicated EPS bearer context 

If the UE receives an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message with an EPS 
bearer identity identical to the EPS bearer identity of an already activated dedicated EPS bearer context, the UE 
shall locally deactivate the existing dedicated EPS bearer context and proceed with the requested dedicated EPS 
bearer context activation. 

c) No default EPS bearer context with linked EPS bearer identity activated 



If the linked EPS bearer identity included in the ACTIVATE DEDICATED EPS BEARER CONTEXT 
REQUEST message does not match the EPS bearer identity of any activated default EPS bearer context, the UE 
shall reply with an ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT message with ESM cause 
#43 "invalid EPS bearer identity". 



The following abnormal cases can be identified: 

a) Expiry of timer T3485: 

On the first expiry of the timer T3485, the MME shall resend the ACTIVATE DEDICATED EPS BEARER 
CONTEXT REQUEST and shall reset and restart timer T3485. This retransmission is repeated four times, i.e. on 
the fifth expiry of timer T3485, the MME shall abort the procedure, release any resources allocated for this 
activation and enter the state BEARER CONTEXT INACTIVE. 

b) Collision of UE requested PDN disconnect procedure and dedicated EPS bearer context activation procedure: 

When the MME receives a PDN DISCONNECT REQUEST message during the dedicated EPS bearer context 
activation procedure, and the EPS bearer to be activated belongs to the PDN connection the UE wants to 



6.4.2.5 



Abnormal cases in the UE 



6.4.2.6 



Abnormal cases on the network side 
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disconnect, the MME shall terminate the dedicated bearer context activation procedure locally, release any 
resources related to this procedure and proceed with the PDN disconnect procedure. 

6.4.3 EPS bearer context modification procedure 

6.4.3.1 General 

The purpose of the EPS bearer context modification procedure is to modify an EPS bearer context with a specific QoS 
and TFT. The EPS bearer context modification procedure is initiated by the network, but it may also be initiated as part 
of the UE requested bearer resource allocation procedure or the UE requested bearer resource modification procedure. 

The network may also initiate the EPS bearer context modification procedure to update the APN-AMBR of the UE, for 
instance after an inter-system handover. See 3GPP TS 23.401 [10] annex E. 

6.4.3.2 EPS bearer context modification initiated by the network 

The MME shall initiate the EPS bearer context modification procedure by sending a MODIFY EPS BEARER 
CONTEXT REQUEST message to the UE, starting the timer T3486, and entering the state BEARER CONTEXT 
MODIFY PENDING (see example in figure 6.4.3.2.1). 

The MME shall include an EPS bearer identity that identifies the EPS bearer context to be modified in the MODIFY 
EPS BEARER CONTEXT REQUEST message. 

The MODIFY EPS BEARER CONTEXT REQUEST message shall include also a procedure transaction identity (PTI), 
if this procedure was initiated by a UE requested bearer resource allocation procedure or a UE requested bearer resource 
modification procedure. 

UE Network 

MODIFY EPS BEARER CONTEXT REQUEST 



MODIFY EPS BEARER CONTEXT ACCEPT 
OR 

MODIFY EPS BEARER CONTEXT REJECT 



Start T3486 



Stop T3486 



Stop T3486 



Figure 6.4.3.2.1 : EPS bearer context modification procedure 

6.4.3.3 EPS bearer context modification accepted by the UE 

Upon receipt of the MODIFY EPS BEARER CONTEXT REQUEST message, the UE shall first check the received 
TFT before taking it into use and then send a MODIFY EPS BEARER CONTEXT ACCEPT message to the MME. 

If the PTI is included in the MODIFY EPS BEARER CONTEXT REQUEST message, the UE uses the PTI to identify 
the UE requested bearer resource allocation procedure or the UE requested bearer resource modification procedure to 
which the EPS bearer context modification is related (see subclause 6.5.3 and subclause 6.5.4). 

If the PTI is included in the MODIFY EPS BEARER CONTEXT REQUEST message and the PTI is associated to a UE 
requested bearer resource allocation procedure or a UE requested bearer resource modification procedure, the UE shall 
release the traffic flow aggregate description associated to the PTI value provided. 

The UE shall use the received TFT to apply mapping of uplink traffic flows to the radio bearer if the TFT contains 
packet filters for the upUnk direction. 
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Upon receipt of the MODIFY EPS BEARER CONTEXT ACCEPT message, the MME shall stop the timer T3486 and 
enter the state BEARER CONTEXT ACTIVE. 

6.4.3.4 EPS bearer context modification not accepted by tine UE 

Upon receipt of the MODIFY EPS BEARER CONTEXT REQUEST message, the UE may reject the request from the 
MME by sending a MODIFY EPS BEARER CONTEXT REJECT message to the MME. The message shall include the 
EPS bearer identity and an ESM cause value indicating the reason for rejecting the EPS bearer context modification 
request. 

The MODIFY EPS BEARER CONTEXT REJECT message contains an ESM cause that typically indicates one of the 
following ESM cause values: 



#26: 


insufficient resources; 


#41: 


semantic error in the TFT operation; 


#42: 


syntactical error in the TFT operation; 


#43: 


invalid EPS bearer identity; 


#44: 


semantic error(s) in packet filter(s); 


#45: 


syntactical error(s) in packet filter(s); 


#46: 


EPS bearer context without TFT already activated; or 


#95- 


111: protocol errors . 



The UE shall check the TFT in the request message for different types of TFT IE errors as follows: 

- semantic errors in the TFT operations; 
syntactical errors in the TFT operations; 

- semantic errors in packet filters; and 

- syntactical errors in packet filters, 

as indicated in 3GPP TS 24.008 [13], subclause 6.1.3.3.3, and shall reject the request message if TFT IE errors are 
detected. 

Upon receipt of the MODIFY EPS BEARER CONTEXT REJECT message with ESM cause value other than #43 
"invalid EPS bearer identity" in state BEARER CONTEXT MODIFY PENDING, the MME shall stop the timer T3486, 
enter the state BEARER CONTEXT ACTIVE and abort the EPS bearer context modification procedure. When the 
MME detects that after the failed EPS bearer context modification there is a misalignment between the EPS bearer 
configuration and the EPS bearer context configuration or between the QoS on NAS and AS level, the MME should 
initiate the necessary procedures to achieve a re-alignment. 

6.4.3.5 Abnormal cases in the UE 

No abnormal cases have been identified. 

6.4.3.6 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) Expiry of timer T3486: 

On the first expiry of the timer T3486, the MME shall resend the MODIFY EPS BEARER CONTEXT 
REQUEST and shall reset and restart timer T3486. This retransmission is repeated four times, i.e. on the fifth 
expiry of timer T3486, the MME shall abort the procedure and enter the state BEARER CONTEXT ACTIVE. 

The MME may continue to use the previous configuration of the EPS bearer context or initiate an EPS bearer 
context deactivation procedure. 
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b) Collision of UE requested PDN disconnect procedure and EPS bearer context modification: 

When the MME receives a PDN DISCONNECT REQUEST message during an EPS bearer context modification 
procedure, and the EPS bearer to be modified belongs to the PDN connection the UE wants to disconnect, the 
MME shaU terminate the EPS bearer context modification procedure locally, release any resources related to this 
procedure and proceed with the PDN disconnect procedure. 



The purpose of the EPS bearer context deactivation procedure is to deactivate an EPS bearer context or disconnect from 
a PDN by deactivating all EPS bearer contexts to the PDN. The EPS bearer context deactivation procedure is initiated 
by the network, and it may be triggered by the UE by means of the UE requested bearer resource modification 
procedure or UE requested PDN discormect procedure. 



If a NAS signalling connection exists when the MME initiates the EPS bearer context deactivation procedure, the MME 
shall initiate the EPS bearer context deactivation procedure by sending a DEACTIVATE EPS BEARER CONTEXT 
REQUEST message to the UE, start the timer T3495, and enter the state BEARER CONTEXT INACTIVE PENDING 
(see example in figure 6.4.4.2.1). The DEACTIVATE EPS BEARER CONTEXT REQUEST message contains an ESM 
cause typically indicating one of the following: 

#8: operator determined barring; 

#36: regular deactivation; 

#38: network failure; or 

#1 12: APN restriction value incompatible with active EPS bearer context. 

The procedure transaction identity (PTI) shall also be included if the deactivation is triggered by a UE initiated bearer 
resource modification procedure or UE requested PDN disconnect procedure. 

When the MME wants to deactivate all EPS bearer contexts to a PDN and thus disconnect the UE from the PDN, the 
MME shall include the EPS bearer identity of the default bearer associated to the PDN in the DEACTIVATE EPS 
BEARER CONTEXT REQUEST message. 

If no NAS signalling connection exists when the MME initiates the EPS bearer context deactivation, the ESM entity in 
the MME shall locally deactivate the EPS bearer context towards the UE without any peer-to-peer ESM signalling 
between the MME and the UE. 

NOTE: The EPS bearer context state(s) can be synchronized between the UE and the MME at the next EMM- 
IDLE to EMM-CONNECTED transition, e.g. during a service request or tracking area updating 
procedure. 



6.4.4 EPS bearer context deactivation procedure 



6.4.4.1 



General 



6.4.4.2 



EPS bearer context deactivation initiated by tlie network 



UE 



Netvs^ork 



DEACTIVATE EPS BEARER CONTEXT REQUEST 



Start T3495 



DEACTIVATE EPS BEARER CONTEXT ACCEPT 



Stop T3495 



Figure 6.4.4.2.1 : EPS bearer context deactivation procedure 
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6.4.4.3 EPS bearer context deactivation accepted by tine UE 

Upon receipt of the DEACTIVATE EPS BEARER CONTEXT REQUEST message, the UE shall delete the EPS bearer 
context identified by the EPS bearer identity. After deactivating the identified EPS bearer context, the UE shall respond 
to the MME with the DEACTIVATE EPS BEARER CONTEXT ACCEPT. 

If the EPS bearer identity indicated in the DEACTIVATE EPS BEARER CONTEXT REQUEST does not point to an 
existing EPS bearer context, the UE shall respond with a DEACTIVATE EPS BEARER CONTEXT ACCEPT with the 
EPS bearer identity set to the received EPS bearer identity. 

If the EPS bearer identity indicated in the DEACTIVATE EPS BEARER CONTEXT REQUEST is that of the default 
bearer to a PDN, the UE shall delete all EPS bearer contexts associated to the PDN. After deactivating all EPS bearer 
contexts, the UE shall respond to the MME with the DEACTIVATE EPS BEARER CONTEXT ACCEPT. 

Upon sending the DEACTIVATE EPS BEARER CONTEXT ACCEPT message, the UE shall enter the state BEARER 
CONTEXT INACTIVE 

If the PTI is included in the DEACTIVATE EPS BEARER CONTEXT REQUEST message, the UE uses the PTI to 
identify the UE requested bearer resource modification procedure or UE requested PDN disconnect procedure to which 
the EPS bearer context deactivation is related (see subclause 6.5.4). 

If the PTI is included in the DEACTIVATE EPS BEARER CONTEXT REQUEST message, the UE shall release the 
traffic flow aggregate description associated to the PTI value provided. 

Upon receipt of the DEACTIVATE EPS BEARER CONTEXT ACCEPT message, the MME shall enter the state 
BEARER CONTEXT INACTIVE and stop the timer T3495. 

6.4.4.4 Abnormal cases in the UE 

Apart from the generic case described in subclause 6.3.2, no abnormal cases have been identified. 

6.4.4.5 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) Expiry of timer T3495: 

On the first expiry of the timer T3495, the MME shaU resend the DEACTIVATE EPS BEARER CONTEXT 
REQUEST and shall reset and restart timer T3495. This retransmission is repeated four times, i.e. on the fifth 
expiry of timer T3495, the MME shall abort the procedure and deactivate the EPS bearer context locally without 
any peer-to-peer ESM signalUng between the MME and the UE. 

b) Collision of UE requested PDN disconnect procedure and EPS bearer context deactivation: 

When the MME receives a PDN DISCONNECT REQUEST message during the EPS bearer context deactivation 
procedure, and the EPS bearer indicated in the DEACTIVATE EPS BEARER CONTEXT REQUEST message 
is a dedicated EPS bearer belonging to the PDN connection the UE wants to disconnect, the MME shall proceed 
with both procedures. If the EPS bearer indicated in the DEACTIVATE EPS BEARER CONTEXT REQUEST 
message is the default EPS bearer, the MME shall proceed with the EPS bearer context deactivation procedure. 

6.4.4.6 Local EPS bearer context deactivation without ESM signalling 

The UE and the MME deactivate EPS bearer contexts locally without peer-to-peer ESM signalling in the following 
cases: 

1) during the service request procedure, if the E-UTRAN fails to establish the user plane radio bearers for one or 
more EPS bearer contexts e.g. due to radio access control; 

2) during the tracking area updating procedure with "active flag", if the E-UTRAN fails to establish the user plane 
radio bearers for one or more EPS bearer contexts due to lower layer failure; 

NOTE 1 : The synchronisation of the EPS bearers indicated in EPS bearer context status information element in 
TRACKING AREA UPDATE REQUEST message is not applicable in item 2. 
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3) during handover, if the target E-UTRAN cannot establish all the user plane radio bearers for the UE; or 

4) if the E-UTRAN releases one or more user plane bearers of the UE due to E-UTRAN specific reasons. 

For those cases, based on the indication from the lower layers, the UE and the MME shall locally deactivate the EPS 
bearer contexts for which no user plane radio bearers are set up. 

NOTE 2: The lower layers in the UE provide the user plane radio bearer context status to the ESM sublayer when a 
change in the user plane radio bearers is detected by the lower layers including establishment and release 
of user plane radio bearers for the UE in connected mode. This does not apply to the release of the RRC 
connection due to an SI -release procedure or due to radio link failure. 

When the user plane radio bearer for a default EPS bearer context is not established during the service request 
procedure or tracking area updating procedure with "active flag", the UE shall locally deactivate all EPS bearer contexts 
associated to the PDN cormection with the default EPS bearer context. The MME shall locally deactivate all EPS bearer 
contexts associated to the PDN connection with the default EPS bearer context without peer-to-peer ESM signalling to 
the UE. 

Upon completion of the service request procedure or tracking area updating procedure with "active flag", if the UE 
locally deactivates all EPS bearer contexts, the UE shall perform a local detach, enter state EMM-DEREGISTERED 
and initiate an attach procedure. 

For EPS bearer context deactivation procedure initiated by the network, if no NAS signalling connection exists, the 
MME locally deactivates the EPS bearer context(s) without peer-to-peer ESM signalling. 

6.5 UE requested ESM procedures 

6.5.1 UE requested PDN connectivity procedure 

6.5.1.1 General 

The purpose of the UE requested PDN connectivity procedure is for a UE to request the setup of a default EPS bearer to 
a PDN. The UE requests connectivity to a PDN by sending a PDN CONNECTIVITY REQUEST message to the 
network. If accepted by the network, this procedure initiates the establishment of a default EPS bearer context. The 
procedure is used either to estabhsh the first default bearer by including the PDN CONNECTIVITY REQUEST 
message into the initial attach message, or to establish subsequent default bearers to additional PDNs in order to allow 
the UE simultaneous access to multiple PDNs by sending the message stand-alone. 

6.5.1 .2 UE requested PDN connectivity procedure initiation 

When the PDN CONNECTIVITY REQUEST message is sent together with an ATTACH REQUEST message, the UE 
shall not include the APN. 

NOTE: If the UE needs to provide PCO which require ciphering or provide an APN, or both, during the attach 

procedure, the ESM information transfer flag is included in the PDN CONNECTIVITY REQUEST. The 
MME then at a later stage in the PDN connectivity procedure initiates the ESM information request 
procedure in which the UE can provide the MME with PCO or APN or both. 

In order to request connectivity to a PDN using the default APN, the UE includes the access point name IE in the PDN 
CONNECTIVITY REQUEST message or, when applicable, in the ESM INFORMATION RESPONSE message, 
according to the following conditions: 

- if use of a PDN using the default APN requires PAP/CHAP, then the UE should include the access point name 
IE; and 

- in all other conditions, the UE need not include the access point name IE. 

In order to request connectivity to an additional PDN, the UE shall send a PDN CONNECTIVITY REQUEST message 
including a requested APN to the MME, start timer T3482 and enter the state PROCEDURE TRANSACTION 
PENDING (see example in figure 6.5.1.2.1). In the PDN type information element the UE shall indicate the IP version 
capability of the IP stack associated with the UE as specified in subclause 6.4.1 
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The UE shall set the request type to "initial request" when the UE is establishing connectivity to a PDN for the first 
time, i.e. when it is an initial attach to that PDN. The UE shall set the request type to "handover" when the connectivity 
to a PDN is established upon handover from a non-3GPP access network and the UE was connected to that PDN before 
the handover to the 3GPP access network. 

If the UE supports DSMIPv6, the UE may include a request for obtaining the IPv6 address and optionally the IPv4 
address of the home agent in the Protocol configuration options IE in the PDN CONNECTIVITY REQUEST message. 
The UE may also include a request for obtaining the IPv6 Home Network Prefix. The UE shall request the IPv6 Home 
Network Prefix only if the UE has requested the home agent IPv6 address. The requested home agent address(es) and 
the Home Network Prefix are related to the APN the UE requested connectivity for. 

The UE may set the ESM information transfer flag in the PDN CONNECTIVITY REQUEST message to indicate that it 
has ESM information, i.e. protocol configuration options, APN, or both, that needs to be sent after the NAS signalling 
security has been activated between the UE and the MME.A PCO provided by the ESM INFORMATION RESPONSE 
replaces any PCO provided by the PDN CONNECTIVITY REQUEST message. 

UE Network 

Start T3482 PDN CONNECTIVITY REQUEST 



rr^^.^^ ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST 
Stop T3482 



OR 

PDN CONNECTIVITY REJECT 



Stop T3482 



Figure 6.5.1.2.1: UE requested PDN connectivity procedure 

6.5.1 .3 UE requested PDN connectivity procedure accepted by tine network 

Upon receipt of the PDN CONNECTIVITY REQUEST message, the MME checks whether the ESM information 
transfer flag is included. If the flag is included the MME waits for completion of the ESM information request 
procedure before proceeding with the PDN connectivity procedure. The MME then checks if connectivity with the 
requested PDN can be established. If no requested APN is included in the PDN CONNECTIVITY REQUEST message 
or the ESM INFORMATION RESPONSE message, the MME shall use the default APN as requested APN. 

If connectivity with the requested PDN is accepted by the network, the MME shall initiate the default EPS bearer 
context activation procedure (see subclause 6.4.1). 

If connectivity with the requested PDN is accepted, but with a restriction of IP version (i.e. both an IPv4 address and an 
IPv6 prefix is requested, but only one particular IP version, or only single IP version bearers are supported/allowed by 
the network), ESM cause #50 "PDN type IPv4 only allowed", #51 "PDN type IPv6 only allowed", or #52 "single 
address bearers only allowed", respectively, shall be included in the ACTIVATE DEFAULT EPS BEARER 

CONTEXT REQUEST message. 

Upon receipt of the message ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST, the UE shall stop timer 
T3482 and enter the state PROCEDURE TRANSACTION INACTIVE. 

6.5.1 .4 UE requested PDN connectivity procedure not accepted by tlie network 

If connectivity with the requested PDN cannot be accepted by the network, the MME shall send a PDN 
CONNECTIVITY REJECT message to the UE. The message shall contain the PTI and an ESM cause value indicating 
the reason for rejecting the UE requested PDN connectivity. 
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Upon receipt of the PDN CONNECTIVITY REJECT message, the UE shall stop timer T3482 and enter the state 
PROCEDURE TRANSACTION INACTIVE. 

The PDN CONNECTIVITY REJECT message contains an ESM cause IE that typically indicates one of the following 
ESM cause values: 



JJ.O . 

#8: 


operator determined barring; 


#26: 


insufficient resources; 


#27: 


missing or unknown APN; 


#28: 


unknown PDN type; 


#29: 


user authentication failed; 


#30: 


activation rejected by Serving GW or PDN GW; 


#31: 


activation rejected, unspecified; 


#32: 


service option not supported; 


#33: 


requested service option not subscribed; 


#34: 


service option temporarily out of order; 


#35: 


PTI already in use; 


#38: 


network failure; 


#50: 


PDN type IPv4 only allowed; 


#51: 


PDN type IPv6 only allowed; 


#53: 


ESM information not received; 


#54: 


PDN connection does not exist; 


#55: 


multiple PDN connections for a given APN not allowed; 


#95- 


111: protocol errors ; 



#1 12: APN restriction value incompatible with active EPS bearer context. 

6.5.1 .5 Abnormal cases in the UE 

The following abnormal cases can be identified: 
a) T3482 expired 

On the first expiry of the timer T3482, the UE shall resend the PDN CONNECTIVITY REQUEST and shall 
reset and restart timer T3482. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3482, 
the UE shall abort the procedure, release the PTI allocated for this invocation and enter the state PROCEDURE 
TRANSACTION E^ACTIVE; 

6.5.1 .6 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) UE initiated PDN connectivity request for an already existing PDN connection: 

If the network receives a PDN CONNECTIVITY REQUEST message with the same combination of APN and 

PDN type as an already existing PDN connection, 

If the information elements in the PDN CONNECTIVITY REQUEST message do not differ from the ones 
received within the previous PDN CONNECTIVITY REQUEST message, and the MME has not received 
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the ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message from UE, the network shall 
resend the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message and continue the 
previous procedure. 

If the one or more information elements in the PDN CONNECTIVITY REQUEST message differs from the 
ones received within the previous PDN CONNECTIVITY REQUEST message, and the multiple PDN 
connections for a given APN are not allowed, the network may deactivate the existing EPS bearer contexts 
for the PDN connection locally without notification to the UE and proceed with the requested PDN 

connectivity procedure or may reject this PDN connectivity procedure including the ESM cause #55 
"multiple PDN connections for a given APN not allowed", in the PDN CONNECTIVITY REJECT message. 

b) UE initiated PDN connectivity request with request type "handover" for a PDN connection that does not exist: 

If the network receives a PDN CONNECTIVITY REQUEST message for either a default APN or a specific 
APN with request type set to "handover" and the MME does not have any information about that PDN 
connection, then MME shall reject the PDN connectivity request procedure including the ESM cause #54 "PDN 
connection does not exist", in the PDN CONNECTIVITY REJECT message. 

c) ESM information not received: 

If the ESM information transfer flag in the PDN CONNECTIVITY REQUEST message has been set and the 
ESM information is not received before the final expiry of timer T3489 as described in subclause 6.6.1.2.6, the 
MME shall reject the PDN connectivity request procedure including the ESM cause #53 "ESM information not 
received", in the PDN CONNECTIVITY REJECT message. 

6.5.2 UE requested PDN disconnect procedure 

6.5.2.1 General 

The purpose of the UE requested PDN disconnection procedure is for a UE to request disconnection from one PDN. 

The UE can initiate this procedure to disconnect from any PDN as long as it is connected to at least one other PDN. 
With this procedure, all EPS bearer contexts established towards this PDN, including the default EPS bearer context, 
are released. 

6.5.2.2 UE requested PDN disconnection procedure initiation 

In order to request PDN disconnection from a PDN, the UE shall send a PDN DISCONNECT REQUEST message to 
the MME, start the timer T3492 and enter the state PROCEDURE TRANSACTION PENDING (see example in 
figure 6.5.2.2.1). The PDN DISCONNECT REQUEST message shall include the EPS bearer identity of the default 
bearer associated with the PDN to discormect from as the linked EPS bearer identity in the PDN DISCONNECT 
REQUEST message. 

UE Network 

Start T3492 PDN DISCONNECT REQUEST 



rr^^.r.^ DEACTIVATE EPS BEARER CONTEXT REQUEST 

Stop T3492 - 



Stop T3492 



OR 

PDN DISCONNECT REJECT 



Figure 6.5.2.2.1: UE requested PDN disconnection procedure 
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6.5.2.3 UE requested PDN disconnection procedure accepted by tine network 

Upon receipt of the PDN DISCONNECT REQUEST message, if it is accepted by the network, the MME shall initiate 
the bearer context deactivation procedure by sending the DEACTIVATE EPS BEARER CONTEXT REQUEST 
message including the linked EPS bearer identity of the default bearer associated with the PDN to disconnect from and 
the PTI. The behaviour of the MME is described in subclause 6.4.4. 

Upon receipt of the DEACTIVATE EPS BEARER CONTEXT REQUEST message, the UE shall stop the timer T3492 
and enter the state PROCEDURE TRANSACTION INACTIVE. The behaviour of the UE is described in 
subclause 6.4.4. 

On reception of DEACTIVATE EPS BEARER CONTEXT ACCEPT message from the UE, the MME releases all the 
resources reserved for the PDN in the network. 

6.5.2.4 UE requested PDN disconnection procedure not accepted by tlie network 

Upon receipt of the PDN DISCONNECT REQUEST message, if it is not accepted by the network, the MME shall send 
a PDN DISCONNECT REJECT message to the UE. The PDN DISCONNECT REJECT message shall contain the PTI 
and an ESM cause IE that typically indicates one of the following ESM cause values: 

#35 : PTI already in use; 

#43: invalid EPS bearer identity; 

#49: last PDN disconnection not allowed; 

#95 - 111: protocol errors. 

Upon receipt of the PDN DISCONNECT REJECT message, the UE shall stop the timer T3492, enter the state 
PROCEDURE TRANSACTION INACTIVE and abort the PDN disconnection procedure. Additionally, in all cases 
with the exception of the UE having received ESM cause #49 "last PDN disconnection not allowed", the UE shall 
deactivate all EPS bearer contexts for this PDN connection locally without peer-to-peer signalUng between the UE and 
the MME. 

6.5.2.5 Abnormal cases in tine UE 

The following abnormal cases can be identified: 

a) Expiry of timer T3492: 

On the first expiry of the timer T3492, the UE shall resend the PDN DISCONNECT REQUEST and shall reset 
and restart timer T3492. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3492, the 
UE shall abort the procedure, deactivate all EPS bearer contexts for this PDN connection locally without peer-to- 
peer signalling between the UE and the MME, and enter the state PROCEDURE TRANSACTION INACTIVE. 
In order to synchronize EPS bearer contexts status with the MME, on indication of "back to E-UTRAN 
coverage" from the lower layers, the UE shall send a TRACKING AREA UPDATE REQUEST message to the 
MME. 

b) Collision of UE requested PDN disconnect procedure and dedicated EPS bearer context activation procedure: 

When the UE receives an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message during the 
PDN disconnect procedure, and the EPS bearer to be activated belongs to the PDN connection the UE wants to 
disconnect, the UE shall ignore the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message 
and proceed with the PDN disconnect procedure. 

c) Collision of UE requested PDN disconnect procedure and EPS bearer context modification: 

When the UE receives a MODIFY EPS BEARER CONTEXT REQUEST message during the PDN disconnect 
procedure, and the EPS bearer to be modified belongs to the PDN connection the UE wants to disconnect, the 
UE shall ignore the MODIFY EPS BEARER CONTEXT REQUEST message and proceed with the PDN 
disconnect procedure. 

d) Collision of UE requested PDN disconnect procedure and EPS bearer context deactivation procedure: 
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When the UE receives a DEACTIVATE EPS BEARER CONTEXT REQUEST message during the PDN 
disconnect procedure, and the EPS bearer indicated in the DEACTIVATE EPS BEARER CONTEXT 
REQUEST message is a dedicated EPS bearer belonging to the PDN connection the UE wants to discormect, the 
UE shall proceed with both procedures. 

6.5.2.6 Abnormal cases on the network side 

The following abnormal cases can be identified: 

a) No PDN connection with the linked EPS bearer identity activated: 

If the hnked EPS bearer identity included in the PDN DISCONNECT REQUEST message does not belong to 
the default EPS bearer context of an established PDN connection, the MME shall reply with a PDN 
DISCONNECT REJECT message with ESM cause #43 "invalid EPS bearer identity". 

6.5.3 UE requested bearer resource allocation procedure 

6.5.3.1 General 

The piupose of the UE requested bearer resource allocation procedure is for a UE to request an allocation of bearer 
resources for a traffic flow aggregate. The UE requests a specific QoS demand (QCI) and optionally sends a GBR 
requirement for a new traffic flow aggregate. If accepted by the network, this procedure invokes a dedicated EPS bearer 
context activation procedure (see subclause 6.4.2) or an EPS bearer context modification procedure (see 
subclause 6.4.3). 

6.5.3.2 UE requested bearer resource allocation procedure initiation 

In order to request the allocation of bearer resources for one traffic flow aggregate, the UE shall send a BEARER 
RESOURCE ALLOCATION REQUEST message to the MME, start timer T3480 and enter the state PROCEDURE 
TRANSACTION PENDING (see example in figure 6.5.3.2.1). 

The UE shall include the EPS bearer identity of the default EPS bearer associated with the requested bearer resource in 
the Linked EPS bearer identity IE. The UE shall set the TFT operation code in the Traffic flow aggregate IE to "Create 
new TFT". In the Required traffic flow QoS IE, the UE shall indicate a QCI and, if the UE also includes a GBR, the 
additional GBR required for the traffic flow aggregate. 

UE Network 



Start T3480 bearer resource allocation request 

ACTIVATE DEDICATED EPS BEARER CONTEXT 
StopT3480 R F "H F- ^T 

OR 

MODIFY EPS BEARER CONTEXT REQUEST 

Stop T3480 



Stop T3480 



OR 

BEARER RESOURCE ALLOCATION REJECT 



Figure 6.5.3.2.1 : UE requested bearer resource allocation procedure 
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6.5.3.3 UE requested bearer resource allocation procedure accepted by the network 

Upon receipt of the BEARER RESOURCE ALLOCATION REQUEST message, the MME checks whether the 
resources requested by the UE can be established by verifying the EPS bearer identity given in the Linked EPS bearer 
identity IE to be any of the active default EPS bearer context(s). 

If the bearer resource allocation requested is accepted by the network, the MME shall initiate either a dedicated EPS 
bearer context activation procedure or an EPS bearer context modification procedure. Upon receipt of an ACTIVATE 
DEDICATED EPS BEARER CONTEXT REQUEST or MODIFY EPS BEARER CONTEXT REQUEST with a PTI 
which matches the value used for the BEARER RESOURCE ALLOCATION REQUEST, the UE shall stop timer 
T3480 and enter the state PROCEDURE TRANSACTION INACTIVE. 

If the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST is received, the UE shall verify that the EPS 
bearer identity given in the EPS bearer identity IE is not already used by any dedicated EPS bearer contexts associated 
with the included linked EPS bearer identity. The UE shall then proceed as described in subclause 6.4.2.3 or subclause 
6.4.2.4. 

If the MODIFY EPS BEARER CONTEXT REQUEST is received, the UE verifies that the EPS bearer identity given in 
the EPS bearer identity IE is any of the active EPS bearer contexts. The UE shall then proceed as described in subclause 

6.4.3.3 or subclause 6.4.3.4. 

6.5.3.4 UE requested bearer resource allocation procedure not accepted by the 
network 

If the bearer resource allocation requested cannot be accepted by the network, the MME shall send a BEARER 
RESOURCE ALLOCATION REJECT message to the UE. The message shall contain the PTI and an ESM cause value 
indicating the reason for rejecting the UE requested bearer resource allocation. 

The ESM cause value typically indicates one of the following: 



#26: 


insufficient resources; 


#30: 


activation rejected by Serving GW or PDN GW; 


#31: 


activation rejected, imspecified; 


#32: 


service option not supported; 


#33: 


requested service option not subscribed; 


#34: 


service option temporarily out of order; 


#35: 


PTI already in use; 


#37: 


EPS QoS not accepted; 


#41: 


semantic error in the TFT operation; 


#42: 


syntactical error in the TFT operation; 


#43: 


invalid EPS bearer identity; 


#44: 


semantic error(s) in packet filter(s); 


#45: 


syntactical error(s) in packet filter(s); 


#46: 


EPS bearer context without TFT already activated; 


#56: 


collision with network initiated request; or 



#95 -111: protocol errors. 
If the requested new TFT is not available, then the BEARER RESOURCE ALLOCATION REJECT shall be sent. 
The TFT in the request message is checked by the network for different types of TFT IE errors as follows: 
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a) semantic errors in the TFT operations; 

b) syntactical errors in the TFT operations; 

c) semantic errors in packet filters; and 

d) syntactical errors in packet filters, 

as indicated in 3GPP TS 24.008 [13], subclause 6.1.3.3.3. 

Upon receipt of a BEARER RESOURCE ALLOCATION REJECT message, the UE shall stop the timer T3480, release 
the traffic flow aggregate description associated to the PTI value, and enter the state PROCEDURE TRANSACTION 
INACTIVE. 

The fiirther actions to be performed by the UE are implementation dependent as part of upper layers responsibility. 

6.5.3.5 Abnormal cases in the UE 

The following abnormal cases can be identified: 

a) Expiry of timer T3480: 

On the first expiry of the timer T3480, the UE shall resend the BEARER RESOURCE ALLOCATION 
REQUEST and shall reset and restart timer T3480. This retransmission is repeated four times, i.e. on the fifth 
expiry of timer T3480, the UE shall abort the procedure, release the PTI allocated for this activation and enter 
the state PROCEDURE TRANSACTION INACTIVE. 

b) Unknown EPS bearer context 

Upon receipt of the BEARER RESOURCE ALLOCATION REJECT message including ESM cause #43 
"invalid EPS bearer identity", the UE shall deactivate the existing default EPS bearer context locally without 
peer-to-peer signalling between the UE and the MME. 

6.5.3.6 Abnormal cases on the network side 

The following abnormal case can be identified: 

a) No PDN connection with the linked EPS bearer identity activated: 

If the linked EPS bearer identity included in the BEARER RESOURCE ALLOCATION REQUEST message 
does not belong to the default EPS bearer context of an established PDN connection, the MME shall reply with a 
BEARER RESOURCE ALLOCATION REJECT message with ESM cause #43 "invalid EPS bearer identity". 

6.5.4 UE requested bearer resource modification procedure 

6.5.4.1 General 

The purpose of the UE requested bearer resource modification procedure is for a UE to request a modification or release 
of bearer resources for a traffic flow aggregate or modification of a traffic flow aggregate by replacing a packet filter. 
When requesting a modification of bearer resources for a traffic flow aggregate or a modification of a traffic flow 
aggregate, the UE can modify the existing GBR. If accepted by the network, this procedure invokes a dedicated EPS 
bearer context activation procedure (see subclause 6.4.2), an EPS bearer context modification procedure (see 
subclause 6.4.3), or an EPS bearer context deactivation procedure (see subclause 6.4.4). 

6.5.4.2 UE requested bearer resource modification procedure initiation 

In order to request the modification of bearer resources for one traffic flow aggregate, the UE shall send a BEARER 
RESOURCE MODIFICATION REQUEST message to the MME, start timer T3481 and enter the state PROCEDURE 
TRANSACTION PENDING (see example in figure 6.5.3.2.1). 

The UE shall include the EPS bearer identity of the EPS bearer associated with the traffic flow aggregate in the EPS 
bearer identity for packet filter IE. 
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To request a change of the GBR without changing the packet fiher(s), the UE shall set the TFT operation code in the 
Traffic flow aggregate IE to "no TFT operation" and include the packet filter identifier(s) to which the change of the 
GBR applies in the Packet filter identifier parameter in the parameters list. The UE shall indicate the new GBR 
requested for the EPS bearer context in the Required traffic flow QoS IE. 

To request a modification of a traffic flow aggregate, the UE shall set the TFT operation code in the Traffic flow 
aggregate IE to "Replace packet filters in existing TFT". If the EPS bearer is a GBR bearer, the UE shall indicate the 
new GBR requested for the EPS bearer context in the Required traffic flow QoS IE. 

To request a release of bearer resources, the UE shall set the TFT operation code in the Traffic flow aggregate IE to 
"Delete packet filters from existing TFT". If the EPS bearer is a GBR bearer, the UE shall indicate the new GBR 
requested for the EPS bearer context in the Required traffic flow QoS IE. 

If the UE requests the release of bearer resources, the ESM cause value typically indicates one of the following: 
#36: regular deactivation. 

UE Network 



Start T3481 bearer resource modification request 

ACTIVATE DEDICATED EPS BEARER CONTEXT 
Stop T3481 R E QU E ST 

OR 



Stop T3481 
Stop T3481 

Stop T3481 



MODIFY EPS BEARER CONTEXT REQUEST 
OR 

DEACTIVATE EPS BEARER CONTEXT REQUEST 
OR 

BEARER RESOURCE MODIFICATION REJECT 



Figure 6.5.3.2.1: UE requested bearer resource modification procedure 

6.5.4.3 UE requested bearer resource modification procedure accepted by tine 
network 

Upon receipt of the BEARER RESOURCE MODIFICATION REQUEST message, the MME checks whether the 
resources requested by the UE can be estabUshed, modified or released by verifying the EPS bearer identity given in the 
EPS bearer identity for packet filter IE. 

If the bearer resource modification requested is accepted by the network, the MME shall initiate either a dedicated EPS 
bearer context activation procedure, an EPS bearer context modification procedure or an EPS bearer context 
deactivation procedure. 

Upon receipt of an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST, MODIFY EPS BEARER 
CONTEXT REQUEST or DEACTIVATE EPS BEARER CONTEXT REQUEST with a PTI which matches the value 
used for the BEARER RESOURCE MODIFICATION REQUEST, the UE shall stop timer T3481 and enter the state 
PROCEDURE TRANSACTION INACTIVE. 

i) If the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST is received, the UE shall verify that the 
EPS bearer identity given in the EPS bearer identity IE is not already used by any dedicated EPS bearer contexts 
associated with the included linked EPS bearer identity. The UE shall then proceed as described in 
subclause 6.4.2.3 or subclause 6.4.2.4. 
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ii) If the MODIFY EPS BEARER CONTEXT REQUEST is received, the UE verifies that the EPS bearer identity 
given in the EPS bearer identity IE is any of the active EPS bearer contexts. The UE shall then proceed as 
described in subclause 6.4.3.3 or subclause 6.4.3.4. 

iii) If the DEACTIVATE EPS BEARER CONTEXT REQUEST is received, the UE verifies that the EPS bearer 

identity given in the EPS bearer identity IE is any of the active EPS bearer contexts associated with the included 
hnked EPS bearer identity The UE shall then proceed as described in subclause 6.4.4.3. 

In case i, after successful completion of the dedicated EPS bearer context activation procedure, the network may initiate 
an EPS bearer context modification procedure to delete the packet filters which have packet filter identifiers indicated 
by the UE in the TFT IE in the BEARER RESOURCE MODIFICATION REQUEST message and for which the 
network created new packet filters during the dedicated EPS bearer context activation procedure. In this case the MME 
shall set the procedure transaction identity value in the MODIFY EPS BEARER CONTEXT REQUEST message to "no 
procedure transaction identity assigned". 

6.5.4.4 UE requested bearer resource modification procedure not accepted by the 
network 

If the bearer resource modification requested cannot be accepted by the network, the MME shall send a BEARER 
RESOURCE MODIFICATION REJECT message to the UE. The message shall contain the PTI and an ESM cause 
value indicating the reason for rejecting the UE requested bearer resource modification. 

The ESM cause value typically indicates one of the following: 



#26: 


insufficient resources; 


#30: 


activation rejected by Serving GW or PDN GW; 


#31: 


activation rejected, imspecified; 


#32: 


service option not supported; 


#33: 


requested service option not subscribed; 


#34: 


service option temporarily out of order; 


#35: 


PTI already in use; 


#37: 


EPS QoS not accepted; 


#41: 


semantic error in the TFT operation; 


#42: 


syntactical error in the TFT operation; 


#43: 


invalid EPS bearer identity; 


#44: 


semantic error(s) in packet filter(s); 


#45: 


syntactical error(s) in packet filter(s); 


#46: 


EPS bearer context without TFT already activated; 


#56: 


collision with network initiated request; or 



#95 -111: protocol errors. 
If the requested new TFT is not available, then the BEARER RESOURCE MODIHCATION REJECT shall be sent. 
The TFT in the request message is checked by the network for different types of TFT IE errors as follows: 

a) semantic errors in the TFT operations; 

b) syntactical errors in the TFT operations; 

c) semantic errors in packet filters; and 

d) syntactical errors in packet filters. 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 



129 



ETSI TS 124 301 V8.2.1 (2009-06) 



as indicated in 3GPP TS 24.008 [13], subclause 6.1.3.3.3. 

Upon receipt of a BEARER RESOURCE MODIFICATION REJECT message, the UE shall stop the timer T3481, 
release the traffic flow aggregate description associated to the PTI value, and enter the state PROCEDURE 
TRANSACTION INACTIVE. 

The further actions to be performed by the UE are implementation dependent as part of upper layers responsibility. 

6.5.4.5 Abnormal cases in the UE 

The following abnormal cases can be identified: 

a) Expiry of timer T3481: 

On the first expiry of the timer T3481, the UE shall resend the BEARER RESOURCE MODIFICATION 
REQUEST and shall reset and restart timer T3481. This retransmission is repeated four times, i.e. on the fifth 
expiry of timer T3481, the UE shall abort the procedure, release the PTI allocated for this activation and enter 
the state PROCEDURE TRANSACTION INACTIVE. In addition, if the UE had initiated resource release for all 
the traffic flows for the bearer, it shall deactivate the EPS bearer context locally without peer-to-peer signalling 
between the UE and the MME. In order to synchronize the EPS bearer context status with the MME, on 
indication of "back to E-UTRAN coverage" from the lower layers, the UE shall send a TRACKING AREA 
UPDATE REQUEST message to the MME. 

b) Unknown EPS bearer context 

Upon receipt of the BEARER RESOURCE MODIFICATION REJECT message including ESM cause #43 
"invalid EPS bearer identity", the UE shall deactivate the existing EPS bearer context locally without peer-to- 
peer signalling between the UE and the MME. 

c) Collision of a UE requested bearer resource modification procedure and an EPS bearer context deactivation 
procedure. 

When the UE receives a DEACTIVATE EPS BEARER CONTEXT REQUEST message during the bearer 
resource modification procedure, and the EPS bearer identity indicated in the DEACTIVATE EPS BEARER 
CONTEXT REQUEST message is a EPS bearer context the UE indicated in the UE requested bearer resource 
modification procedure, then the UE shall abort the UE requested bearer resource modification procedure and 
proceed with the EPS bearer context deactivation procedure. 

6.5.4.6 Abnormal cases on the network side 

a) Unknown EPS bearer context 

If the EPS bearer identity provided in the EPS bearer identity for packet filter IE in the BEARER RESOURCE 
MODIFICATION REQUEST message indicates an EPS bearer identity value and this does not belong to any 
already activated EPS bearer context, the MME shall reply with a BEARER RESOURCE MODIFICATION 
REJECT message with ESM cause #43 "invaUd EPS bearer identity". 

6.6 Miscellaneous procedures 

6.6.1 Exchange of protocol configuration options 

6.6.1.1 General 

The UE and the PDN-GW can exchange protocol configuration options via the dedicated ESM information request 
procedure or via other ESM procedures. 
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6.6.1 .2 ESM information request procedure 

6.6.1.2.1 General 

The ESM information request procedure is used by the network to retrieve ESM information, i.e. protocol configuration 
options, APN, or both from the UE during the attach procedure if the UE indicated in the PDN CONNECTIVITY 
REQUEST message that it has ESM information that needs to be sent security protected. The purpose of this procedure 
is to provide privacy for the ESM information if ciphering is enabled in the network. 

6.6.1 .2.2 ESM information request initiated by tine network 

The network inflates the ESM information request procedure by sending a ESM INFORMATION REQUEST message 
to the UE, starting timer T3489 and entering the state PROCEDURE TRANSACTION PENDING (see example in 
figure 6.6.1.2.2.1). This message shall be sent only after the security context has been setup, and if the ESM information 
transfer flag has been set in the PDN CONNECTIVITY REQUEST message. The MME shall set the EPS bearer 
identity of the ESM INFORMATION REQUEST message to the value "no EPS bearer identity assigned" and include 
the PTl from the associated PDN CONNECTIVITY REQUEST message. 

UE Network 



ESM INFORMATION REQUEST ^ 

^ Start T3489 



ESM INFORMATION RESPONSE ^ g^^p T3489 



Figure 6.6.1.2.2.1: ESM information request procedure 

6.6.1 .2.3 ESM information request completion by the UE 

Upon receipt of the ESM INFORMATION REQUEST message, the UE shall send an ESM INFORMATION 
RESPONSE message to the network .The UE shall include all the protocol configuration options that need to be 
transferred security protected, and APN if required, to the network in the ESM INFORMATION RESPONSE message. 
The UE shall set the EPS bearer identity of the ESM INFORMATION RESPONSE message to the value "no EPS 
bearer identity assigned" and include the PTI from the ESM INFORMATION REQUEST message. 

6.6.1 .2.4 ESM information request completion by the network 

Upon receipt of the ESM INFORMATION RESPONSE message, the network shall stop timer T3489 and enter the 
state PROCEDURE TRANSACTION INACTIVE. A PCO included in the ESM INFORMATION RESPONSE 
message replaces any PCO that the network previously may have received during the attach procedure execution. 

6.6.1 .2.5 Abnormal cases in the UE 

No abnormal cases have been identified. 

6.6.1 .2.6 Abnormal cases on the network side 

The following abnormal cases can be identified: 
a) Expiry of timer T3489: 

On the first expiry of the timer T3489, the MME shall resend the ESM INFORMATION REQUEST message 
and shall reset and restart timer T3489. This retransmission is repeated two times, i.e. on the third expiry of timer 
T3489, the MME shall abort the procedure, release any resources for this procedure and reject the associated 
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PDN connectivity procedure including the ESM cause #53 "ESM information not received", in the PDN 
CONNECTIVITY REJECT message. 



6.6.1.3 



Exchange of protocol configuration options in otiier messages 



The UE may include a Protocol configuration options IE on EPS bearer context activation, EPS bearer context 

deactivation, EPS bearer context modification, PDN connectivity request, PDN disconnect request, bearer resource 
allocation request and bearer resource modification request if the UE wishes to transmit (protocol) data (e.g. 
configuration parameters, error codes or messages/events) to the PDN-GW. 

The PDN-GW may include a Protocol configuration options IE on EPS bearer context activation, EPS bearer context 
deactivation, EPS bearer context modification, PDN connectivity reject, PDN disconnect reject, bearer resource 
allocation reject and bearer resource modification reject if the PDN-GW wishes to transmit (protocol) data (e.g. 
configuration parameters, error codes or messages/events) to the UE. 



6.7 Reception of an ESM STATUS message by an ESM entity 



The purpose of the sending of the ESM STATUS message is to report at any time certain error conditions detected upon 
receipt of ESM protocol data. The ESM STATUS message can be sent by both the MME and the UE (see example in 
figure 6.7.1). 

If the ESM entity of the UE receives an ESM STATUS message the UE shall take different actions depending on the 
received ESM cause value: 

#97 (Message type non-existent or not implemented); 

The UE shall abort any ongoing ESM procedure related to the PTI or EPS bearer identity and stop any related 



On receipt of an ESM STATUS message with any other ESM cause value no state transition and no specific action shall 
be taken as seen from the radio interface, i.e. local actions are possible. 

If the ESM entity of the MME receives an ESM STATUS message the MME shall take different actions depending on 
the received ESM cause value: 



The MME shall abort any ongoing ESM procedure related to the PTI or EPS bearer identity and stop any related 



The local actions to be taken by the MME on receipt of an ESM STATUS message with any other ESM cause value are 
implementation dependent. 



timer. 



#97 



(Message type non-existent or not implemented); 



timer. 



UE 



Network 



ESM STATUS 



OR 



ESM STATUS 



Figure 6.7.1 : ESM status procedure 
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7 Handling of unknown, unforeseen, and erroneous 
protocol data 

7.1 General 

The procedures specified in the present document apply to those messages which pass the checks described in this 

subclause. 

This subclause also specifies procedures for the handUng of unknown, unforeseen, and erroneous protocol data by the 
receiving entity. These procedures are called "error handling procedures", but in addition to providing recovery 
mechanisms for error situations they define a compatibiUty mechanism for future extensions of the protocols. 

Subclauses 7.1 to 7.8 shall be applied in order of precedence. 

Most error handling procedures are mandatory for the UE. 

Detailed error handling procedures in the network are implementation dependent and may vary from PLMN to PLMN. 
However, when extensions of this protocol are developed, networks will be assumed to have the error handling that is 
indicated in this subclause as mandatory ("shall") and that is indicated as strongly recommended ("should"). 

Also, the error handling of the network is only considered as mandatory or strongly recommended when certain 
thresholds for errors are not reached during a dedicated connection. 

For definition of semantical and syntactical errors see 3GPP TS 24.007 [12], subclause 11.4.2. 

7.2 Message too short 

When a message is received that is too short to contain a complete message type information element, that message 
shall be ignored, cf. 3GPP TS 24.007 [12]. 

7.3 Unknown or unforeseen procedure transaction identity or 
EPS bearer identity 

7.3.1 Procedure transaction identity 

The following network procedures shall apply for handUng an unknown, erroneous, or unforeseen PTI received in an 
ESM message: 

a) If the network receives a PDN CONNECTIVITY REQUEST message with an unassigned or reserved PTI value, 
the network shall respond with a PDN CONNECTIVITY REJECT message including ESM cause #81 "invalid 
PTI value". 

b) If the network receives a PDN DISCONNECT REQUEST message with an unassigned or reserved PTI value, 
the network shall respond with a PDN DISCONNECT REJECT message including ESM cause #81 "invalid PTI 
value". 

c) If the network receives a BEARER RESOURCE ALLOCATION REQUEST message with an unassigned or 
reserved PTI value, the network shall respond with a BEARER RESOURCE ALLOCATION REJECT message 
including ESM cause #81 "invalid PTI value". 

d) If the network receives a BEARER RESOURCE MODIFICATION REQUEST message with an unassigned or 
reserved PTI value, the network shall respond with a BEARER RESOURCE MODIFICATION REJECT 
message including ESM cause #81 "invalid PTI value". 

e) If the network receives an ESM message other than those listed in items a) through d) above with a reserved PTI 
value, the network shall ignore the message. 
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The following UE procedures shall apply for handling an unknown, erroneous, or unforeseen PTI received in an ESM 

message: 

a) If the UE receives a PDN CONNECTIVITY REJECT message in which the PTI value is an assigned value that 
does not match any PTI in use, the UE shall ignore the message. 

b) If the UE receives an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message in which the PTI 
value is an assigned value that does not match any PTI in use, the UE shall respond with an ACTIVATE 
DEFAULT EPS BEARER CONTEXT REJECT message including ESM cause #47 "PTI mismatch". 

c) If the UE receives an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message which contains a 
reserved or unassigned PTI value, the UE shall respond with an ACTIVATE DEFAULT EPS BEARER 
CONTEXT REJECT message including ESM cause #81 "invaUd PTI value". 

d) If the UE receives a PDN DISCONNECT REJECT message in which the PTI value is an assigned value that 
does not match any PTI in use, the UE shall ignore the message. 

e) If the UE receives a BEARER RESOURCE ALLOCATION REJECT message in which the PTI value is an 
assigned value that does not match any PTI in use, the UE shall ignore the message. 

f) If the UE receives a BEARER RESOURCE MODIFICATION REJECT message in which the PTI value is an 
assigned value that does not match any PTI in use, the UE shall ignore the message. 

g) If the UE receives a MODIFY EPS BEARER CONTEXT REQUEST message in which the PTI value is an 
assigned value that does not match any PTI in use, the UE shall respond with a MODIFY EPS BEARER 
CONTEXT REJECT message including ESM cause #47 "PTI mismatch". 

h) If the UE receives a MODIFY EPS BEARER CONTEXT REQUEST message which contains a reserved PTI 
value, the UE shall respond with a MODIFY EPS BEARER CONTEXT REJECT message including ESM cause 
#81 "invalid PTI value". 

i) If the UE receives an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message in which the 
PTI value is an assigned value that does not match any PTI in use, the UE shall respond with an ACTIVATE 
DEDICATED EPS BEARER CONTEXT REJECT message including ESM cause #47 "PTI mismatch". 

j) If the UE receives an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message which 
contains a reserved PTI value, the UE shall respond with an ACTIVATE DEDICATED EPS BEARER 
CONTEXT REJECT message including ESM cause #81 "invaUd PTI value". 

k) If the UE receives a DEACTIVATE EPS BEARER CONTEXT REQUEST message in which the PTI value is 
an assigned value that does not match any PTI in use, the UE shall ignore the message. 

1) If the UE receives an ESM INFORMATION REQUEST message in which the PTI value is an assigned value 
that does not match a PTI in use for a pending UE requested PDN connectivity procedure for which the ESM 
information transfer flag was set in the PDN CONNECTIVITY REQUEST message, the UE shall ignore the 
message. 

m) If the UE receives an ESM message other than those Usted in items a) through 1) with a reserved PTI value, the 
UE shall ignore the message. 

7.3.2 EPS bearer identity 

The following network procedures shall apply for handling an unknown, erroneous, or unforeseen EPS bearer identity 
received in the header of an ESM message (specified as the header of a standard L3 message, see 
3GPP TS 24.007 [12]): 

a) If the network receives a PDN CONNECTIVITY REQUEST message which includes an assigned or reserved 
EPS bearer identity value, the network shall respond with a PDN CONNECTIVITY REJECT message including 
ESM cause #43 "invalid EPS bearer identity". 

b) If the network receives a PDN DISCONNECT REQUEST message which includes an assigned or reserved EPS 
bearer identity value, the network shall respond with a PDN DISCONNECT REJECT message including ESM 
cause #43 "invalid EPS bearer identity". 
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c) If the network receives a BEARER RESOURCE ALLOCATION REQUEST message which includes an 
assigned or reserved EPS bearer identity value, the network shall respond with a BEARER RESOURCE 
ALLOCATION REJECT message including ESM cause #43 "invalid EPS bearer identity". 

d) If the network receives a BEARER RESOURCE MODIFICATION REQUEST message which includes an 
assigned or reserved EPS bearer identity value, the network shall respond with a BEARER RESOURCE 
MODIFICATION REJECT message including ESM cause #43 "invalid EPS bearer identity". 

e) If the network receives an ESM message other than those listed in items a) through d) above in which the 
message includes a reserved EPS bearer identity value or an assigned value that does not match an EPS bearer 
context of an established PDN connection, the network shall ignore the message. 

The following UE procedures shall apply for handling an unknown, erroneous, or unforeseen EPS bearer identity 
received in an ESM message: 

a) If the UE receives an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message which includes 
an unassigned or reserved EPS bearer identity value, the UE shall respond with an ACTIVATE DEFAULT EPS 
BEARER CONTEXT REJECT message including ESM cause #43 "invalid EPS bearer identity". 

b) If the UE receives an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message which 
includes an unassigned or reserved EPS bearer identity value, the UE shall respond with an ACTIVATE 
DEDICATED EPS BEARER CONTEXT REJECT message including ESM cause #43 "invaUd EPS bearer 
identity". 

c) If the UE receives a MODIFY EPS BEARER CONTEXT REQUEST message which includes an unassigned or 
reserved EPS bearer identity value or an assigned EPS bearer identity value that does not match an EPS bearer 
context of an estabUshed EPS bearer, the UE shall respond with a MODIFY EPS BEARER CONTEXT REJECT 
message including ESM cause #43 "invalid EPS bearer identity". 

d) If the UE receives a DEACTIVATE EPS BEARER CONTEXT REQUEST message which includes an EPS 
bearer identity value that does not match an existing EPS bearer context, the UE behaviour is described in 
subclause 6.4.4.3. 

e) If the UE receives an ESM message other than those listed in items a) through d) in which the message includes 
an unassigned or reserved EPS bearer identity value or a value that does not match an EPS bearer context of an 
established PDN cormection, the UE shall ignore the message. 

7.4 Unknown or unforeseen message type 

If UE receives an EMM message or ESM message with message type not defined for the protocol discriminator (PD) or 
not implemented by the receiver, it shall return a status message (EMM STATUS or ESM STATUS depending on the 
PD) with cause #97 "message type non-existent or not implemented". 

If the network receives an EMM or ESM message with message type not defined for the PD or not implemented by the 
receiver in a protocol state where reception of an unsolicited message with the given PD from the UE is not foreseen in 
the protocol, the network actions are implementation dependent. Otherwise, if the network receives a message with 
message type not defined for the PD or not implemented by the receiver, it shall ignore the message except that it 
should return a status message (EMM STATUS or ESM STATUS depending on the PD) with cause #97 "message type 
non-existent or not implemented" . 

NOTE: A message type not defined for the PD in the given direction is regarded by the receiver as a message 
type not defined for the PD, see 3GPP TS 24.007 [12]. 

If the UE receives a message not compatible with the protocol state, the UE shall return a status message (EMM 
STATUS or ESM STATUS depending on the PD) with cause #98 "message type not compatible with protocol state". 

If the network receives a message not compatible with the protocol state, the network actions are implementation 
dependent. 
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7.5 Non-semantical mandatory information element errors 

7.5.1 Common procedures 

When on receipt of a message, 

- an "imperative message part" error; or 

- a "missing mandatory IE" error 

is diagnosed or when a message containing: 

- a syntactically incorrect mandatory IE; 

- an IE unknown in the message, but encoded as "comprehension required" (see 3GPP TS 24.007 [12]); or 

- an out of sequence IE encoded as "comprehension required" (see 3GPP TS 24.007 [12]) is received, 

the UE shall proceed as foUows: 

If the message is not one of the messages listed in subclause 7.5.3, item a), b), c), or d), the UE shall return a 
status message (EMM STATUS or ESM STATUS depending on the PD) with cause #96 "invalid mandatory 

information"; and 

the network shall proceed as follows: 

If the message is not one of the messages listed in subclause 7.5.3, item e), f), g) or h), the network shall either: 

- try to treat the message (the exact further actions are implementation dependent); or 

- ignore the message except that it should return a status message (EMM STATUS or ESM STATUS 
depending on the PD) with cause #96 "invahd mandatory information". 

7.5.2 EPS mobility management 

No exceptional cases are described for mobility management messages. 

No semantical or syntactical diagnosis other than presence and length shall be performed on the ESM message 
container information element in the ATTACH REQUEST, ATTACH ACCEPT and ATTACH COMPLETE messages. 

7.5.3 EPS session management 

The following UE procedures shall apply for handling an error encountered with a mandatory information element in an 
ESM message: 

a) If the message is an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST, an ACTIVATE DEFAULT 
EPS BEARER CONTEXT REJECT message with ESM cause #96 "invalid mandatory information", shall be 
returned. 

b) If the message is an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST, an ACTIVATE 
DEDICATED EPS BEARER CONTEXT REJECT message with ESM cause #96 "invalid mandatory 
information", shall be returned. 

c) If the message is a MODIFY EPS BEARER CONTEXT REQUEST, a MODIFY EPS BEARER CONTEXT 
REJECT message with ESM cause #96 "invalid mandatory information", shall be returned. 

d) If the message is a DEACTIVATE EPS BEARER CONTEXT REQUEST, a DEACTIVATE EPS BEARER 
CONTEXT ACCEPT message shall be returned. AH resources associated with that EPS bearer shall be released. 

The following network procedures shall apply for handUng an error encountered with a mandatory information element 
in an ESM message: 

e) If the message is a PDN CONNECTIVITY REQUEST, a PDN CONNECTIVITY REJECT message with ESM 
cause #96 "invalid mandatory information", shall be returned. 
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f) If the message is a PDN DISCONNECT REQUEST, a PDN DISCONNECT REJECT message with ESM cause 

#96 "invalid mandatory information", shall be returned. 

g) If the message is a BEARER RESOURCE ALLOCATION REQUEST, a BEARER RESOURCE 
ALLOCATION REJECT message with ESM cause #96 "invalid mandatory information", shall be returned. 

h) If the message is a BEARER RESOURCE MODIFICATION REQUEST, a BEARER RESOURCE 
MODIFICATION REJECT message with ESM cause #96 "invalid mandatory information", shall be returned. 

7.6 Unknown and unforeseen lEs in the non-imperative 
message part 

7.6.1 lEIs unknown in the message 

The UE shall ignore all lEs unknown in a message which are not encoded as "comprehension required" (see 
3GPP TS 24.007 [12]). 

The network shall take the same approach. 

7.6.2 Out of sequence lEs 

The UE shall ignore all out of sequence lEs in a message which are not encoded as "comprehension required" (see 
3GPP TS 24.007 [12]). 

The network should take the same approach. 

7.6.3 Repeated IBs 

If an information element with format T, TV, TLV, or TLV-E is repeated in a message in which repetition of the 
information element is not specified in clause 8 of the present document, the UE shall handle only the contents of the 
information element appearing first and shall ignore all subsequent repetitions of the information element. When 
repetition of information elements is specified, the UE shall handle only the contents of specified repeated information 
elements. If the limit on repetition of information elements is exceeded, the UE shall handle the contents of information 
elements appearing first up to the limit of repetitions and shall ignore all subsequent repetitions of the information 
element. 

The network should follow the same procedures. 

7.7 Non-imperative message part errors 

This category includes: 

syntactically incorrect optional lEs; and 
conditional IE errors. 

7.7.1 Syntactically incorrect optional IBs 

The UE shall treat all optional lEs that are syntactically incorrect in a message as not present in the message. 
The network shall take the same approach. 

7.7.2 Conditional IB errors 

When upon receipt of a EMM or ESM message the UE diagnoses a "missing conditional IE" error or an "unexpected 
conditional IE" error, or when it receives a EMM or ESM message containing at least one syntactically incorrect 
conditional IE, the UE shall ignore the message and shall return a status message (EMM STATUS or ESM STATUS 
depending on the PD) with cause #100 "conditional IE error". 
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When the network receives a message and diagnoses a "missing conditional IE" error or an "unexpected conditional IE" 
error or when it receives a message containing at least one syntactically incorrect conditional IE, the network shall 
either: 

- try to treat the message (the exact ftirther actions are implementation dependent); or 

- ignore the message except that it should return a status message (EMM STATUS or ESM STATUS depending 
on the PD) with cause #100 "conditional IE error". 

7.8 Messages with semantically incorrect contents 

When a message with semantically incorrect contents is received, the UE shall perform the foreseen reactions of the 
procedural part of the present document (i.e. of clauses 4, 5 and 6). If however no such reactions are specified, the UE 
shall ignore the message except that it shall return a status message (EMM STATUS or ESM STATUS depending on 
the PD) with cause #95 "semantically incorrect message". 

The network should follow the same procedure except that a status message is not normally transmitted. 



8 Message functional definitions and contents 
8.1 Overview 

This clause defines the structure of the messages of the Layer 3 (L3) protocols defined in the present document. These 
are standard L3 messages as defined in 3GPP TS 24.007 [12]. 

Each definition given in the present clause includes: 

a) a brief description of the message direction and use, including whether the message has: 

1. Local significance, i.e. relevant only on the originating or terminating access; 

2. Access significance, i.e. relevant in the originating and terminating access, but not in the network; 

3. Dual significance, i.e. relevant in either the originating or terminating access and in the network; or 

4. Global significance, i.e. relevant in the originating and terminating access and in the network. 

b) a table listing the Information Elements (IE) known in the message and the order of their appearance in the 
message. All lEs that may be repeated are explicitly indicated (The V, LV and LV-E formatted lEs, which 
compose the imperative part of the message, occur before the T, TV, TLV and TLV-E formatted lEs which 
compose the non-imperative part of the message, see 3GPP TS 24.007 [12]). In a (maximal) sequence of 
consecutive lEs with half octet length, the first IE with half octet length occupies bits 1 to 4 of octet N, the 
second IE bits 5 to 8 of octet N, the third IE bits 1 to 4 of octet N+1 etc. Such a sequence always has an even 
number of elements. 

For each information element the table indicates: 

1. The Information Element Identifier (lEl), in hexadecimal notation, if the IE has format T, TV, TLV or 
TLV-E. If the lEI has half octet length, it is specified by a notation representing the lEI as a hexadecimal 
digit followed by a "-" (example: B-). 

NOTE: The same lEI can be used for different information element types in different messages of the same 
protocol. 

2. The name of the information element (which may give an idea of the semantics of the element). The name of 
the information element followed by "IE" or "information element" is used in this technical report as 
reference to the information element within a message. 

3. The name of the type of the information element (which indicates the coding of the value part of the IE), and 
generally, the referenced subclause of clause 9 of the present document describing the value part of the 
information element. 
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4. The presence requirement indication (M, C, or O) for the IE as defined in 3GPP TS 24.007 [12]. 

5. The format of the information element (T, V, TV, LV, TLV, LV-E or TLV-E) as defined in 
3GPP TS 24.007 [12]. 

6. The length of the information element (or permissible range of lengths), in octets, in the message, where "?" 
means that the maximum length of the IE is only constrained by link layer protocol. This indication is non- 
normative. 

c) subclauses specifying, where appropriate, conditions for lEs with presence requirement C or O in the relevant 
message which together with other conditions specified in the present document define when the information 
elements shall be included or not, what non-presence of such lEs means, and - for lEs with presence requirement 
C - the static conditions for presence or non-presence of the lEs or for both cases (see 3GPP TS 24.007 [12]). 

8.2 EPS mobility management messages 

8.2.1 Attach accept 

8.2.1.1 Message definition 

This message is sent by the network to the UE to indicate that the corresponding attach request has been accepted. See 
table 8.2.1.1. 

Message type: ATTACH ACCEPT 

Significance: dual 

Direction: network to UE 
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Table 8.2.1.1 : ATTACH ACCEPT message content 



in 


inToriTiaiion cicincni 


1 yp6/nei6rence 




rormat 






Protocol discriminator 


Protocol discriminator 


M 


V 


1/2 




Security header type 


Security header type 
y.o.1 


M 


V 


1/2 




Attach accept message identity 


IVIessage type 
y.o 


M 


V 


1 




EPS attach result 


EPS attach result 
y.y.^3.^ u 


M 


V 


1/2 




Spare half octet 


Spare half octet 
y.y .ri.y 


M 


V 


1/2 




T3412 value 


GPRS timer 

Q Q Q -1 c; 

y.y.o. J b 


M 


V 


1 




TAI list 


Tracking area identity list 
y.y. o. oo 


M 


LV 


7-97 




ESM message container 


ESM message container 

Q Q '3 1 

y.y.o. 1 


M 


LV-E 


2-n 


50 


GUTI 


EPS mobile identity 





TLV 


13 


13 


Location area identification 


Location area identification 





TV 


6 


23 


MS identity 


Mobile identity 

Q Q Q 

y.y.^.o 





TLV 


7-10 


53 


EMM cause 


EMM cause 

Q Q T Q 

y .y.o.y 





TV 


2 


17 


T3402 value 


GPRS timer 
9.9.3.16 





TV 


2 


59 


T3423 value 


GPRS timer 
9.9.3.16 





TV 


2 


4A 


Equivalent PLMNs 


PLMN list 
9.9.2.8 





TLV 


5-47 


34 


Emergency Number List 


Emergency Number List 
9.9.3.37 





TLV 


5-50 



8.2.1.2 GUTI 

This IE may be included to assign a GUTI to the UE during attach or combined EPS/IMSI attach. 

8.2.1 .3 Location area identification 

This IE may be included to assign a new location area identification to a UE during a combined attach. 

8.2.1.4 MS identity 

This IE may be included to assign or unassign a new TMSI to a UE during a combined attach. 

8.2.1.5 EMM cause 

This IE shall be included when IMSI attach for non-EPS services is not successful during a combined EPS/IMSI attach 
procedure. 

8.2.1.6 T3402 value 

This IE may be included to indicate a value for timer T3402. 
If this IE is not included, the UE shall use the default value. 
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8.2.1.7 T3423 value 

This IE may be included to indicate a value for timer T3423. 
If this IE is not included, the UE shall use the default value. 

8.2.1.8 Equivalent PLMNs 

This IE may be included in order to assign a new equivalent PLMNs list to a UE. 

8.2.1 .9 Emergency Number List 

This IE may be sent by the network. If this IE is sent, the contents of this IE indicates a list of emergency numbers valid 
within the same MCC as in the cell on which this IE is received. 

8.2.2 Attach complete 

This message is sent by the UE to the network in response to an ATTACH ACCEPT message. See table 8.2.2.1. 
Message type: ATTACH COMPLETE 

Significance: dual 
Direction: UE to network 



Table 8.2.2.1 : ATTACH COMPLETE message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security tieader type 


Security hieader type 
9.3.1 


M 


V 


1/2 




Attacti complete message identity 


Message type 
9.8 


M 


V 


1 




ESM message container 


ESM message container 
9.9.3.15 


M 


LV-E 


2-n 



8.2.3 Attach reject 
8.2.3.1 Message definition 

This message is sent by the network to the UE to indicate that the corresponding attach request has been rejected. See 
table 8.2.3.1. 

Message type: ATTACH REJECT 

Significance: dual 

Direction: network to UE 
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Table 8.2.3.1 : ATTACH REJECT message content 



IPI 


inTOllTlallOn EII6n16ni 


1 ypc/neierence 




ruriTiai 






Protocol discriminator 


Protocol discriminator 

Q 9 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Attach reject message identity 


Message type 
9.8 


M 


V 


1 




ElVIIVI cause 


EMM cause 
9.9.3.9 


M 


V 


1 


78 


ESIVI message container 


ESM message container 
9.9.3.15 





TLV-E 


4-n 



8.2.3.2 ESM message container 

This IE is included to carry a single ESM message. 

8.2.4 Attach request 
8.2.4.1 Message definition 

This message is sent by the UE to the network in order to perform an attach procedure. See table 8.2.4.1. 
Message type: ATTACH REQUEST 
Significance: dual 
Direction: UE to network 
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Table 8.2.4.1 : ATTACH REQUEST message content 



in 


inToriTiaiion cicincni 


1 yp6/nei6rence 




rormat 






Protocol discriminator 


Protocol discriminator 


M 


V 


1/2 




Security header type 


Security header type 
y.o.1 


M 


V 


1/2 




Attacli request message identity 


Message type 
y.o 


M 


V 


1 




EPS attach type 


EPS attach type 

Q O O H H 

y.y.o.1 1 


M 


V 


1/2 




NAS l<ey set Identifier 


NAS key set identifier 
y.y .o.iii 


M 


V 


1/2 




Old GUT! or IMSI 


EPS mobile identity 


M 


LV 


5-12 




UE networl< capability 


UE network capability 
y.y. o. o4 


M 


LV 


3-14 




ESM message container 


ESM message container 

Q Q '3 1 c: 

y.y.o. 1 


M 


LV-E 


2-n 


19 


Old P-TMSI signature 


P-TMSI signature 

H n c c Q 





TV 


4 


50 


Additional GUTI 


EPS mobile identity 

Q Q Q i O 

y.y.o. 1 





TLV 


13 


52 


Last visited registered TAI 


Tracking area identity 
y.y. o.o*:! 





TV 


6 


5C 


DRX parameter 


DRX parameter 

Q Q Q Q 

y.y.o.o 





TV 


3 


31 


MS network capability 


MS network capability 
Q Q o on 





TLV 


4-10 


13 


Old location area identification 


Location area identification 

Q Q 9 9 





TV 


6 


9- 


TMSI status 


TMSI Status 
9.9.3.31 





TV 


1 


11 


Mobile station classmark 2 


Mobile station classmark 2 
9.9.2.4 





TLV 


5 


20 


Mobile station classmark 3 


Mobile station classmark 3 
9.9.2.5 





TLV 


2-34 


40 


Supported Codecs 


Supported Codec List 
9.9.2.10 





TLV 


5-n 



8.2.4.2 Old P-TMSI signature 

The UE shaU include this IE if the TIN indicates "P-TMSI" and the UE holds a valid P-TMSI signature, P-TMSI and 
RAI. 

8.2.4.3 Additional GUTI 

The UE shall include this IE if the TIN indicates "P-TMSI" and the UE holds a valid GUTI, P-TMSI and RAI. 

8.2.4.4 Last visited registered TAI 

This IE shall be included if the UE holds a vaUd last visited registered TAI. 

8.2.4.5 DRX parameter 

This IE is included if UE supports A/Gb mode or lu mode or if the UE wants to indicate its UE specific DRX 
parameters to the network. 

8.2.4.6 MS network capability 

A UE supporting A/Gb mode or lu mode shall include this IE to indicate its capabiUties to the network. 
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8.2.4.7 Old location area identification 

The UE shall include this IE during a combined attach procedure if it has a valid location area identification. 

8.2.4.8 TMSI status 

The UE shaU include this IE during combined attach procedure if it has no valid TMSI available. 

8.2.4.9 Mobile station classmark 2 

This IE shall be included if the UE supports SRVCC to GERAN or UTRAN (see 3GPP TS 23.216 [8]). 

8.2.4.10 Mobile station classmark 3 

This IE shall be included if the UE supports SRVCC to GERAN. 

8.2.4.11 Supported Codecs 

This IE shall be included if the UE supports SRVCC to GERAN or UTRAN to indicate its supported speech codecs for 
CS speech calls. 

8.2.5 Authentication failure 
8.2.5.1 Message definition 

This message is sent by the UE to the network to indicate that authentication of the network has failed. See 
table 8.2.5.1. 

Message type: AUTHENTICATION FAILURE 

Significance: dual 

Direction: UE to network 



Table 8.2.5.1 : AUTHENTICATION FAILURE message content 



lEI 


Information element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 

9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Autlientication failure 
message type 


Message type 
9.8 


M 


V 


1 




EMM cause 


EMM cause 
9.9.3.9 


M 


V 


1 


30 


Authentication failure parameter 


Authentication failure parameter 
9.9.3.1 





TLV 


16 



8.2.5.2 Authentication failure parameter 

This IE shall be sent if and only if the EMM cause was #21 "synch failure". It shall include the response to the 
authentication challenge from the USIM, which is made up of the AUTS parameter (see 3GPP TS 33.102 [18]). 

8.2.6 Authentication reject 

This message is sent by the network to the UE to indicate that the authentication procedure has failed and that the UE 
shall abort all activities. See table 8.2.6.1. 

Message type: AUTHENTICATION REJECT 
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Significance: dual 
Direction: network to UE 



Table 8.2.6.1 : AUTHENTICATION REJECT message content 



lEI 


Information element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Authentication reject message 
type 


IVIessage type 
9.8 


IVI 


V 


1 



8.2.7 Authentication request 

This message is sent by the network to the UE to initiate authentication of the UE identity. See table 8.2.7.1. 
Message type: AUTHENTICATION REQUEST 
Significance: dual 
Direction: network to UE 



Table 8.2.7.1 : AUTHENTICATION REQUEST message content 



lEI 


information element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Authentication request message 
type 


Message type 
9.8 


M 


V 


1 




NAS key set IdentifierASME 


NAS key set identifier 
9.9.3.21 


M 


V 


1/2 




Spare half octet 


Spare half octet 
9.9.2.9 


M 


V 


1/2 




Authentication parameter RAND 

(EPS challenge) 


Authentication parameter RAND 
9.9.3.3 


M 


V 


16 




Authentication parameter AUTN 
(EPS challenge) 


Authentication parameter AUTN 
9.9.3.2 


M 


LV 


17 



8.2.8 Authentication response 

This message is sent by the UE to the network to deliver a calculated authentication response to the network. See 
table 8.2.8.1. 

Message type: AUTHENTICATION RESPONSE 
Significance: dual 
Direction: UE to network 
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Table 8.2.8.1 : AUTHENTICATION RESPONSE message content 



lEI 


Information element 


Type/Reference 


Presence 


Format 


Lengtti 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 






Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Authentication response 
message type 


Message type 
9.8 


M 


V 


1 




Authentication response 
parameter 


Authentication response 

parameter 

9.9.3.4 


M 


LV 


5-17 



8.2.9 CS service notification 
8.2.9.1 Message definition 

This message is sent by the network when a paging request with CS call indicator was received via SGs for a UE, and a 
NAS signalling connection is already established for the UE. See table 8.2.9.1. 

Message type: CS SERVICE NOTIFICATION 

Significance: dual 

Direction: network to UE 



Table 8.2.9.1 : CS SERVICE NOTIFICATION message content 



lEI 


information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




CS service notification message 
identity 


Message type 
9.8 


M 


V 


1 




Paging identity 


Paging identity 
9.9.3.25A 


M 


V 


1 


60 


CLI 


CLI 

9.9.3.38 





TLV 


3-14 


61 


SS Code 


SS Code 
9.9.3.39 





TV 


2 


62 


LCS indicator 


LCS indicator 
9.9.3.40 





TV 


2 


63 


LCS client identity 


LCS client identity 
9.9.3.41 





TLV 


3-257 



8.2.9.2 CLI 

The network shall send this IE if it was received via SGs. It contains the identification of the calling line for the mobile 
terminating call in the CS domain, which triggered the paging via SGs. 

8.2.9.3 SS Code 

The network shall send this IE if it was received via SGs. It contains information on the supplementary service 
transaction in the CS domain, which triggered the paging via SGs. 

8.2.9.4 LCS indicator 

The network shall send this IE if it was received via SGs. It indicates that the paging was triggered by a terminating 
LCS request in the CS domain. 
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8.2.9.5 LCS client identity 

The network shall send this IE if received via SGs. It contains information related to the requestor of the terminating 
LCS request in the CS domain. 

8.2.10 Detach accept 

8.2.1 0.1 Detacli accept (UE originating detacli) 

This message is sent by the network to indicate that the detach procedure has been completed. See table 8.2.10.1.1. 
Message type: DETACH ACCEPT 
Significance: dual 
Direction: network to UE 



Table 8.2.10.1.1: DETACH ACCEPT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Detach accept message identity 


l\/lessage type 
9.8 


IVI 


V 


1 



8.2.1 0.2 Detacli accept (UE terminated detach) 

This message is sent by the UE to indicate that the detach procedure has been completed. See table 8.2.10.2.1. 
Message type: DETACH ACCEPT 
Significance: dual 
Direction: UE to network 



Table 8.2.10.2.1: DETACH ACCEPT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


IVI 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Detach accept message identity 


IVIessage type 
9.8 


M 


V 


1 



8.2.11 Detach request 

8.2.1 1 .1 Detach request (UE originating detach) 

This message is sent by the UE to request the release of an EMM context. See table 8.2.11.1.1. 
Message type: DETACH REQUEST 
Significance: dual 
Direction: UE to network 
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Table 8.2.11.1.1: DETACH REQUEST message content 



Id 


inTOllTlallOn EII6n16ni 


1 ype/ncTerencc 




rurmai 






Protocol discriminator 


Protocol discriminator 


M 


V 


1/2 




Security header type 


Security header type 


M 


V 


1/2 




Detach request message identity 


Message type 
9.8 


M 


V 


1 




Detach type 


Detach type 
9.9.3.7 


M 


V 


1/2 




NAS key set identifier 


NAS key set identifier 
9.9.3.21 


M 


V 


1/2 




GUTI or IMSI 


EPS mobile identity 
9.9.3.12 


M 


LV 


5-12 



8.2.1 1 .2 Detach request (UE terminated detach) 
8.2.1 1 .2.1 Message definition 

This message is sent by the network to request the release of an EMM context. See table 8.2.11.2.1. 
Message type: DETACH REQUEST 
Significance: dual 
Direction: network to UE 



Table 8.2.11.2.1: DETACH REQUEST message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Detach request message identity 


Message type 
9.8 


M 


V 


1 




Detach type 


Detach type 
9.9.3.7 


M 


V 


1/2 




Spare half octet 


Spare half octet 
9.9.2.9 


M 


V 


1/2 


53 


EMM cause 


EMM cause 
9.9.3.9 





TV 


2 



8.2.11.2.2 EMM cause 

This information element is included if an EMM cause is provided. 

8.2.1 2 Downlink NAS Transport 

This message is sent by the network to the UE in order to carry an SMS message in encapsulated format. See 
table 8.2.12.1. 

Message type: DOWNLINK NAS TRANSPORT 

Significance: dual 

Direction: network to UE 
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Table 8.2.12.1 : DOWNLINK NAS TRANSPORT message content 



IFI 


iiiiui iiidiiuii t Id lid II 


1 ypc/ndd CI iwc 


r 1 CdCl ILrC 


nViJi 1 1 idi 


ly 11 1 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Downlinl< NAS transport message 
identity 


Message type 
9.8 


M 


V 


1 




NAS message container 


NAS message container 
9.9.3.22 


M 


LV 


3-252 



8.2.13 EMM information 
8.2.13.1 Message definition 

This message is sent by the network at any time during EMM context is established to send certain information to the 
UE. See table 8.2.13.1. 

Message type: EMM INFORMATION 

Significance: local 

Direction: network to UE 



Table 8.2.13.1: EMM INFORMATION message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




EMM information message 
identity 


Message type 
9.8 


M 


V 


1 


43 


Full name for network 


Network name 
9.9.3.24 





TLV 


3-n 


45 


Short name for network 


Network name 
9.9.3.24 





TLV 


3-n 


46 


Local time zone 


Time zone 
9.9.3.29 





TV 


2 


47 


Universal time and local time zone 


Time zone and time 
9.9.3.30 





TV 


8 


49 


Network daylight saving time 


Daylight saving time 
9.9.3.6 





TLV 


3 



8.2. 1 3.2 Full name for network 

This IE may be sent by the network. If this IE is sent, the contents of this IE indicate the "fuU length name of the 
network" that the network wishes the UE to associate with the MCC and MNC contained in the last visited tracking area 
identification. 

8.2. 1 3.3 Short name for network 

This IE may be sent by the network. If this IE is sent, the contents of this IE indicate the "abbreviated name of the 
network" that the network wishes the UE to associate with the MCC and MNC contained in the last visited tracking area 
identification. 
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8.2.13.4 Local time zone 

This IE may be sent by the network. The UE should assume that this time zone applies to the tracking area of the 
current cell, and also appUes to the tracking area list if available in the UE. 

NOTE: The time information can be inaccurate, especially when the TAI Ust includes tracking areas belonging to 
different time zones. 

If the local time zone has been adjusted for dayUght saving time, the network shall indicate this by including the 
Network daylight saving time IE. 

8.2.13.5 Universal time and local time zone 

This IE may be sent by the network. The UE should assume that this time zone applies to the tracking area the UE is 
currently in, and also applies to the tracking area hst if available in the UE. The UE shall not assume that the time 
information is accurate. 

NOTE: The time information can be inaccurate, especially when the TAI list includes tracking areas belonging to 
different time zones. 

If the local time zone has been adjusted for dayUght saving time, the network shall indicate this by including the 
Network daylight saving time IE. 

8.2.1 3.6 Network daylight saving time 

This IE may be sent by the network. If this IE is sent, the contents of this IE indicates the value that has been used to 
adjust the local time zone. 

8.2.14 EMM status 

This message is sent by the UE or by the network at any time to report certain error conditions listed in clause 7. See 
table 8.2.14.1. 

Message type: EMM STATUS 

Significance: local 

Direction: both 



Table 8.2.14.1: EMM STATUS message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security lieader type 
9.3.1 


M 


V 


1/2 




EMIVi status message identity 


Message type 
9.8 


M 


V 


1 




ElVIM cause 


EMM cause 
9.9.3.9 


M 


V 


1 



8.2.15 Extended service request 
8.2.15.1 Message definition 

This message is sent by the UE to the network to initiate a CS fallback call or respond to a mobile terminated CS 
fallback request from the network. See table 8.2.15.1. 

Message type: EXTENDED SERVICE REQUEST 

Significance: dual 
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Direction: UE to network 



Table 8.2.15.1: EXTENDED SERVICE REQUEST message content 



lEI 


information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security lieader type 


Security header type 
9.3.1 


M 


V 


1/2 




Extended service request 
message identity 


Message type 
9.8 


M 


V 


1 




Service type 


Service type 
9.9.3.27 


M 


V 


1/2 




NAS key set identifier 


NAS key set identifier 
9.9.3.21 


IVI 


V 


1/2 




IVI-TIVISI 


IVlobile identity 
9.9.2.3 


M 


LV 


6 


B- 


CSFB response 


CSFB response 
9.9.3.5 


C 


TV 


1 



8.2.15.2 CSFB response 

The UE shall include this IE only if the Service type information element indicates "mobile terminating CS fallback". 

8.2.16 GUTI reallocation command 
8.2.16.1 Message definition 

This message is sent by the network to the UE to reallocate a GUTI and optionally to provide a new TAI list. See 
table 8.2.16.1. 

Message type: GUTI REALLOCATION COMMAND 

Significance: dual 
Direction: network to UE 



Table 8.2.16.1: GUTI REALLOCATION COMMAND message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




GUTI reallocation command 
message identity 


Message type 
9.8 


M 


V 


1 




GUTI 


EPS mobile identity 
9.9.3.12 


M 


LV 


12 


54 


TAI list 


Tracking area identity list 
9.9.3.33 





TLV 


8-98 



8.2.16.2 TAI list 

This IE may be included to assign a TAI Ust to the UE. 

8.2.17 GUTI reallocation complete 

This message is sent by the UE to the network to indicate that reallocation of a GUTI has taken place. See 
table 8.2.17.1. 
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Message type: GUTI REALLOCATION COMPLETE 
Significance: dual 
Direction: UE to network 



Table 8.2.17.1 : GUTI REALLOCATION COMPLETE message content 



IE! 


Information Element 


Type/Reference 


Presence 


Format 


Lengtli 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security lieader type 


Security header type 
9.3.1 


M 


V 


1/2 




GUTI reallocation complete 
message identity 


Message type 
9.8 


M 


V 


1 



8.2.18 Identity request 

This message is sent by the network to the UE to request the UE to provide the specified identity. See table 8.2.18.1. 
Message type: IDENTITY REQUEST 
Significance: dual 
Direction: network to UE 



Table 8.2.18.1: IDENTITY REQUEST message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Identity request message identity 


Message type 
9.8 


M 


V 


1 




Identity type 


Identity type 2 
9.9.3.17 


M 


V 


1/2 




Spare half octet 


Spare half octet 
9.9.2.9 


M 


V 


1/2 



8.2.19 Identity response 

This message is sent by the UE to the network in response to an IDENTITY REQUEST message and provides the 
requested identity. See table 8.2.19.1. 

Message type: IDENTITY RESPONSE 

Significance: dual 

Direction: UE to network 
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Table 8.2.19.1: IDENTITY RESPONSE message content 



IFI 


Infni'iTiatinn Plomont 
iiiiuiiiidiiuii dt?ii Id 11 




1^1 ILrC 


lUi 1 1 idi 






Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Identity response message 


Message type 
9.8 


M 


V 


1 




Mobile identity 


Mobile identity 
9.9.2.3 


M 


LV 


4-10 



8.2.20 Security mode command 
8.2.20.1 Message definition 

This message is sent by the network to the UE to establish NAS signalling security. See table 8.2.20.1. 
Message type: SECURITY MODE COMMAND 
Significance: dual 
Direction: network to UE 



Table 8.2.20.1 : SECURITY MODE COMMAND message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Lengtli 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Security mode command 
message identity 


Message type 
9.8 


M 


V 


1 




Selected NAS security algorithms 


NAS security algorithms 
9.9.3.23 


M 


V 


1 




NAS key set identifier 


NAS key set identifier 
9.9.3.21 


M 


V 


1/2 




Spare half octet 


Spare half octet 
9.9.2.9 


M 


V 


1/2 




Replayed UE security capabilities 


UE security capability 
9.9.3.36 


M 


LV 


3-6 


C- 


IMEISV request 


IMEISV request 
9.9.3.18 





TV 


1 


55 


Replayed nonceuE 


Nonce 
9.9.3.25 





TV 


5 


56 


NonceMME 


Nonce 
9.9.3.25 





TV 


5 



8.2.20.2 IMEISV request 

The MME may include this information element to request the UE to send its IMEISV with the corresponding 
SECURITY MODE COMPLETE message. 

8.2.20.3 Replayed nonceuE 

The MME may include this information element to indicate to the UE to use the replayed nonceuE- 

8.2.20.4 NonceMME 

The MME may include this information element to indicate to the UE to use the nonccMME- 
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8.2.21 Security mode complete 
8.2.21 .1 Message definition 

This message is sent by the UE to the network in response to a SECURITY MODE COMMAND message. See 
table 8.2.21.1. 

Message type: SECURITY MODE COMPLETE 

Significance: dual 

Direction: UE to network 



Table 8.2.21.1 : SECURITY MODE COMPLETE message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Security mode complete message 
identity 


Message type 
9.8 


M 


V 


1 


23 


IMEISV 


Mobile identity 
9.9.2.3 





TLV 


11 



8.2.21.2 IMEISV 

The UE shall include this information element, if the IMEISV was requested within the corresponding SECURITY 
MODE COMMAND message. 

8.2.22 Security mode reject 

This message is sent by the UE to the network to indicate that the corresponding security mode command has been 
rejected. See table 8.2.22.1. 

Message type: SECURITY MODE REJECT 

Significance: dual 

Direction: UE to network 



Table 8.2.22.1 : SECURITY MODE REJECT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Security mode reject message 
identity 


Message type 
9.8 


M 


V 


1 




EMM cause 


EMM cause 
9.9.3.9 


M 


V 


1 



8.2.23 Security protected NAS message 

This message is sent by the UE or the network to transfer a NAS message together with the sequence number and the 
message authentication code protecting the message. See table 8.2.23.1. 

Message type: SECURITY PROTECTED NAS MESSAGE 

Significance: dual 
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Direction: both 



Table 8.2.23.1 : SECURITY PROTECTED NAS MESSAGE message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




IVIessage authentication code 


Message authentication code 
9.5 


M 


V 


4 




Sequence number 


Sequence number 
9.6 


M 


V 


1 




NAS message 


NAS message 
9.7 


M 


V 


1-n 



8.2.24 Service reject 
8.2.24.1 Message definition 

This message is sent by the network to the UE in order to reject the service request procedure. See table 8.2.24.1. 
Message type: SERVICE REJECT 
Significance: dual 
Direction: network to UE 



Table 8.2.24.1: SERVICE REJECT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Service reject message identity 


Message type 
9.8 


M 


V 


1 




EMM cause 


EMM cause 
9.9.3.9 


M 


V 


1 


5B 


T3442 value 


GPRS timer 
9.9.3.16 


C 


TV 


2 



8.2.24.2 T3442 value 

The MME shall include this IE when the EMM cause value is #39 "CS domain temporarily not available". 

8.2.25 Service request 

This message is sent by the UE to the network to request the estabUshment of a NAS signalling connection and of the 
radio and SI bearers. Its structure does not foUow the structure of a standard layer 3 message. See table 8.2.25.1. 

Message type: SERVICE REQUEST 

Significance: dual 

Direction: UE to network 
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Table 8.2.25.1 : SERVICE REQUEST message content 



IFI 


iiiiui iiidiiuii t Id lid II 


1 ypc/ndd CI iwc 


r 1 CdCl ILrC 


nViJi 1 1 idi 


ly 11 1 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




KSI and sequence number 


KSI and sequence number 
9.9.3.19 


M 


V 


1 




IVIessage autlientication code 
(sliort) 


Short MAC 
9.9.3.28 


M 


V 


2 



8.2.26 Tracking area update accept 
8.2.26.1 Message definition 

This message is sent by the network to the UE to provide the UE with EPS mobility management related data in 
response to a tracking area update request message. See table 8.2.26.1. 

Message type: TRACKING AREA UPDATE ACCEPT 

Significance: dual 

Direction: network to UE 



Table 8.2.26.1 : TRACKING AREA UPDATE ACCEPT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Tracking area update accept 
message identity 


Message type 
9.8 


M 


V 


1 




EPS update result 


EPS update result 
9.9.3.13 


M 


V 


1/2 




Spare half octet 


Spare half octet 
9.9.2.9 


M 


V 


1/2 


5A 


T3412 value 


GPRS timer 
9.9.3.16 





TV 


2 


50 


GUTI 


EPS mobile identity 
9.9.3.12 





TLV 


13 


54 


TAI list 


Tracking area identity list 
9.9.3.33 





TLV 


8-98 


57 


EPS bearer context status 


EPS bearer context status 
9.9.2.1 





TLV 


4 


13 


Location area identification 


Location area identification 
9.9.2.2 





TV 


6 


23 


MS identity 


Mobile identity 
9.9.2.3 





TLV 


7-10 


53 


EMM cause 


EMM cause 
9.9.3.9 





TV 


2 


17 


T3402 value 


GPRS timer 
9.9.3.16 





TV 


2 


59 


T3423 value 


GPRS timer 
9.9.3.16 





TV 


2 


4A 


Equivalent PLMNs 


PLMN list 
9.9.2.8 





TLV 


5-47 


34 


Emergency Number List 


Emergency Number List 
9.9.3.37 





TLV 


5-50 
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8.2.26.2 T3412value 

This IE may be included to indicate a value for timer T3412. 

If this IE is not included, the UE shall use the value currently stored, e.g. from a prior ATTACH ACCEPT message. 

8.2.26.3 GUTI 

This IE may be included to assign a GUTI to a UE. 

8.2.26.4 TAI list 

This IE may be included to assign a TAI hst to a UE. 

8.2.26.5 EPS bearer context status 

This IE shall be included if the network wants to indicate the EPS bearer contexts that are active for the UE in the 
network. 

8.2.26.6 Location area identification 

This IE may be included to assign a new location area identification to a UE during a combined TA/LA update. 

8.2.26.7 MS Identity 

This IE may be included to assign or unassign a new TMSI to a UE during a combined TA/LA update. 

8.2.26.8 EMM cause 

This IE shall be included if the combined tracking area updating procedure was successful for EPS services only. 

8.2.26.9 T3402 value 

This IE may be included to indicate a value for timer T3402. 
If this IE is not included, the UE shall use the default value. 

8.2.26.10 T3423 value 

This IE may be included to indicate a value for timer T3423. 
If this IE is not included, the UE shall use the default value. 

8.2.26.11 Equivalent PLMNs 

This IE may be included in order to assign a new equivalent PLMNs list to a UE. 

8.2.26.12 Emergency Number List 

This IE may be sent by the network. If this IE is sent, the contents of this IE indicates a list of emergency numbers valid 
within the same MCC as in the cell on which this IE is received. 

8.2.27 Tracking area update complete 

This message shall be sent by the UE to the network in response to a tracking area update accept message if a GUTI has 
been changed. See table 8.2.27.1. 

Message type: TRACKING AREA UPDATE COMPLETE 
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Significance: dual 
Direction: UE to network 



Table 8.2.27.1 : TRACKING AREA UPDATE COMPLETE message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security tieader type 


Security header type 
9.3.1 


M 


V 


1/2 




Tracking area update complete 
message identity 


Message type 
9.8 


M 


V 


1 



8.2.28 Tracking area update reject 

This message is sent by the network to the UE in order to reject the tracking area updating procedure. See 
table 8.2.28.1. 

Message type: TRACKING AREA UPDATE REJECT 

Significance: dual 
Direction: network to UE 



Table 8.2.28.1 : TRACKING AREA UPDATE REJECT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security header type 


Security header type 
9.3.1 


M 


V 


1/2 




Tracking area update reject 
message identity 


Message type 
9.8 


M 


V 


1 




EMM cause 


EMM cause 
9.9.3.9 


M 


V 


1 



8.2.29 Tracking area update request 
8.2.29.1 Message definition 

The purposes of sending the tracking area update request by the UE to the network are described in subclause 5.5.3.1. 
See table 8.2.29.1. 

Message type: TRACKING AREA UPDATE REQUEST 

Significance: dual 

Direction: UE to network 
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Table 8.2.29.1 : TRACKING AREA UPDATE REQUEST message content 



IPI 


inToriTiaiion ciciiicni 


1 yp6/nei6rence 




roriTiai 


Lcngin 




Protocol discriminator 


Protocol discriminator 


M 


V 


1/2 




Security header type 


Security header type 
y.o.i 


M 


V 


1/2 




Tracking area update 
request messaye lueniiiy 


Message type 
y.c5 


M 


V 


1 




EPS update type 


EPS update type 
9.9.3.14 


M 


V 


1/2 




NAS key set identifier 


NAS key set identifier 
9.9.3.21 


M 


V 


H /O 

1/2 




Uld oU 1 1 


EPS mobile Identity 
9.9.3.12 


M 


1 \ / 

LV 


H O 


b- 


Non-current native NAS key 
set identifier 


NAS key set identifier 
9.9.3.21 


o 


"r\ / 
1 V 


1 


o 

8- 


GPRS clptierlng key 
sequence number 


Ciphering key sequence 

number 

Q Q Q /I o 


o 


"r\ / 
1 V 


1 


19 


Old P-TMSI signature 


P-TMSI signature 





TV 


4 


50 


Additional GUTI 


EPS mobile identity 

Q Q Q H O 

y.y.o.1 <i 





TLV 


13 


55 


NonceuE 


Nonce 
9.9.3.25 





TV 


5 


CO 

58 


UE network capability 


UE network capability 
9.9.3.34 


o 


"Tl \ / 

1 LV 


A H C 

4-15 


CO 

52 


Last visited registered TAI 


Tracking area Identity 
9.9.3.32 


o 


1 V 


o 


50 


DRX parameter 


DRX parameter 
9.9.3.8 


o 


"r\ / 
1 V 


o 

3 


A 

A- 


UE radio capability 
Information update needed 


UE radio capability information 
update needed 
y .y.o.oo 


o 


"r\ / 
1 V 


1 


57 


EPS bearer context status 


EPS bearer context status 

Q Q O 1 





TLV 


4 


31 


MS network capability 


MS network capability 





TLV 


4-10 


13 


Old location area 

lUcilllllL'd.UUll 


Location area identification 

Q Ct 





TV 


6 


9- 


TMSI Status 


TMSI status 
9.9.3.31 





TV 


1 


11 


Mobile station classmark 2 


Mobile station classmark 2 
9.9.2.4 





TLV 


5 


20 


Mobile station classmark 3 


Mobile station classmark 3 
9.9.2.5 





TLV 


2-34 


40 


Supported Codecs 


Supported Codec List 
9.9.2.10 





TLV 


5-n 



8.2.29.2 Non-current native NAS key set identifier 

The UE shall include this IE if the UE has a valid non-current native EPS security context when the UE performs an 
A/Gb mode or lu mode to SI mode inter-system change in EMM-CONNECTED mode and the UE uses a mapped EPS 
security context to protect the TRACKING AREA UPDATE REQUEST message. 

8.2.29.3 GPRS ciphering key sequence number 

The UE shall include this IE if the UE performs an A/Gb mode or lu mode to SI mode inter-system change in EMM- 
IDLE mode and the TIN indicates "P-TMSI". 
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8.2.29.4 Old P-TMSI signature 

The UE shaU include this IE if the TIN indicates "P-TMSI" and the UE holds a valid P-TMSI signature, P-TMSI and 
RAI. 

8.2.29.5 Additional GUTI 

The UE shall include this IE if the TIN indicates "P-TMSl" and the UE holds a valid GUTI, P-TMSl and RAI. 

8.2.29.6 NonceuE 

This IE is included if the UE performs an A/Gb mode or lu mode to SI mode inter-system change in idle mode. 

8.2.29.7 UE network capability 

The UE shall include this IE, unless the UE performs a periodic tracking area updating procedure. 

8.2.29.8 Last visited registered TAI 

This IE shall be included if the UE holds a valid last visited registered TAI. 

8.2.29.9 DRX parameter 

This IE is included by the UE to indicate a change of UE specific DRX parameters to the network. 

8.2.29.10 UE radio capability information update needed 

The UE shall include this IE if the UE radio capability information in the network needs to be updated. 

8.2.29.1 1 EPS bearer context status 

This IE shall be included if the UE wants to indicate the EPS bearer contexts that are active within the UE. 

8.2.29.1 2 MS network capability 

A UE supporting A/Gb mode or lu mode shall include this IE, unless the UE performs a periodic tracking area updating 
procedure. 

8.2.29.13 Old location area identification 

The UE shall include this IE during a combined tracking area updating procedure if it has a valid location area 
identification. 

8.2.29.14 TMSI status 

The UE shall include this IE during a combined tracking area updating procedure if it has no valid TMSI available. 

8.2.29.1 5 Mobile station classmark 2 

This IE shall be included if the UE supports SRVCC to GERAN or UTRAN (see 3GPP TS 23.216 [8]). 

8.2.29.1 6 Mobile station classmark 3 

This IE shall be included if the UE supports SRVCC to GERAN. 
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8.2.29.17 Supported Codecs 

This IE shall be included if the UE supports SRVCC to GERAN or UTRAN to indicate its supported speech codecs for 
CS speech calls. 

8.2.30 Uplink NAS Transport 

This message is sent by the UE to the network in order to carry an SMS message in encapsulated format. See 
table 8.2.30.1. 

Message type: UPLINK NAS TRANSPORT 

Significance: dual 

Direction: UE to network 



Table 8.2.30.1 : UPLINK NAS TRANSPORT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




Security lieader type 


Security header type 
9.3.1 


M 


V 


1/2 




Upllnl< NAS transport message 

identity 


Message type 
9.8 


M 


V 


1 




NAS message container 


NAS message container 
9.9.3.22 


M 


LV 


3-252 



8.3 EPS session management messages 
8.3.1 Activate dedicated EPS bearer context accept 
8.3.1.1 Message definition 

This message is sent by the UE to the network to acknowledge activation of a dedicated EPS bearer context associated 
with the same PDN address(es) and APN as an already active EPS bearer context. See table 8.3. 1. 1. 

Message type: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT 

Significance: dual 

Direction: UE to network 



Table 8.3.1.1: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Activate dedicated EPS bearer 
context accept message identity 


Message type 
9.8 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 
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8.3.1 .2 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 

8.3.2 Activate dedicated EPS bearer context reject 
8.3.2.1 Message definition 

This message is sent by UE to the network to reject activation of a dedicated EPS bearer context. See table 8.3.2.1. 
Message type: ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT 

Significance: dual 
Direction: UE to network 



Table 8.3.2.1 : ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


IVI 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


IVI 


V 


1 




Activate dedicated EPS bearer 
context reject message identity 


IVIessage type 
9.8 


IVI 


V 


1 




ESIVl cause 


ESIVl cause 
9.9.4.4 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.2.2 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 

8.3.3 Activate dedicated EPS bearer context request 

8.3.3.1 Message definition 

This message is sent by the network to the UE to request activation of a dedicated EPS bearer context associated with 
the same PDN address(es) and APN as an already active default EPS bearer context. See table 8.3.3.1. 

Message type: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST 

Significance: dual 

Direction: network to UE 
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Table 8.3.3.1 : ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message content 





iniorniaiion cicincni 


1 ype/rfeference 




ruriTiai 






Protocol discriminator 


Protocol discriminator 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 

Q Q O 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 


M 


V 


1 




Activate dedicated EPS bearer 
coniexi reCjUesi message lueniiiy 


Message type 

Q Q 


M 


V 


1 




Linl<ed EPS bearer identity 


Linked EPS bearer identity 
y.y .4.13 


M 


V 


1/2 




Spare half octet 


Spare half octet 
y.y.^.y 


M 


V 


1/2 




EPS QoS 


EPS quality of service 

Q Q /I Q 


M 


LV 


2-10 




TFT 


Traffic flow template 

O Q A 

y.y .4. 1 


M 


LV 


2-256 


5D 


Transaction identifier 


Transaction identifier 

Q O A iy 

y.y.4.1 / 





TLV 


3-4 


30 


Negotiated QoS 


Quality of service 

Q a A iO 

y .y .4. \ £i 





TLV 


14-18 


32 


Negotiated LLC SAPI 


LLC service access point identifier 
9.9.4.7 





TV 


2 


8- 


Radio priority 


Radio priority 
9.9.4.13 





TV 


1 


34 


Packet flow Identifier 


Packet flow Identifier 
9.9.4.8 





TLV 


3 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.3.2 Transaction identifier 

If the UE supports A/Gb mode or lu mode or both, the network may include this IE 

8.3.3.3 Negotiated QoS 

If the UE supports A/Gb mode or lu mode or both, the network may include the corresponding pre-Rel-8 QoS 
parameter values of a PDP context. 

8.3.3.4 Negotiated LLC SAPI 

If the UE supports A/Gb mode, the network may include this IE. 

8.3.3.5 Radio priority 

If the UE supports A/Gb mode, the network may include this IE. 

8.3.3.6 Packet flow identifier 

If the UE supports A/Gb mode, the network may include this IE. If the UE indicated in the MS network capability it 
does not support BSS packet flow procedures, then the MME shall not include this IE. 

8.3.3.7 Protocol configuration options 

This IE is included in the message when the network wishes to transmit (protocol) data (e.g. configuration parameters, 
error codes or messages/events) to the UE. 
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8.3.4 Activate default EPS bearer context accept 
8.3.4.1 Message definition 

This message is sent by the UE to the network to acknowledge activation of a default EPS bearer context. See 
table 8.3.4.1. 

Message type: ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT 
Significance: dual 
Direction: UE to network 



Table 8.3.4.1 : ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message content 



lEI 


information Eiement 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Activate default EPS bearer 
context accept message identity 


Message type 
9.8 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.4.2 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 

8.3.5 Activate default EPS bearer context reject 
8.3.5.1 Message definition 

This message is sent by UE to the network to reject activation of a default EPS bearer context. See table 8.3.5.1. 
Message type: ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT 
Significance: dual 
Direction: UE to network 



Table 8.3.5.1 : ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


IVI 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Activate default EPS bearer 
context reject message identity 


IVIessage type 
9.8 


M 


V 


1 




ESM cause 


ESIVI cause 
9.9.4.4 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 
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8.3.5.2 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 

8.3.6 Activate default EPS bearer context request 
8.3.6.1 Message definition 

This message is sent by the network to the UE to request activation of a default EPS bearer context. See table 8.3.6.1. 
Message type: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST 

Significance: dual 
Direction: network to UE 



Table 8.3.6.1: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Lengtli 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Activate default EPS bearer 
context request message identity 


Message type 
9.8 


M 


V 


1 




EPS QoS 


EPS quality of service 
9.9.4.3 


M 


LV 


2-10 




Access point name 


Access point name 
9.9.4.1 


M 


LV 


2-101 




PDN address 


PDN address 
9.9.4.9 


M 


LV 


6-14 


5D 


Transaction identifier 


Transaction identifier 
9.9.4.17 





TLV 


3-4 


30 


Negotiated QoS 


Quality of service 
9.9.4.12 





TLV 


14-18 


32 


Negotiated LLC SAP! 


LLC service access point identifier 
9.9.4.7 





TV 


2 


8- 


Radio priority 


Radio priority 
9.9.4.13 





TV 


1 


34 


Packet flow Identifier 


Packet flow Identifier 
9.9.4.8 





TLV 


3 


5E 


APN-AMBR 


APN aggregate maximum bit rate 
9.9.4.2 





TLV 


4-8 


58 


ESM cause 


ESM cause 
9.9.4.4 





TV 


2 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.6.2 Transaction identifier 

If the UE supports A/Gb mode or lu mode or both, the network may include this IE 

8.3.6.3 Negotiated QoS 

If the UE supports A/Gb mode or lu mode or both, the network may include the corresponding pre-Rel-8 QoS 
parameter values of a PDP context. 
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8.3.6.4 Negotiated LLC SAPI 

If the UE supports A/Gb mode, the network may include this IE. 

8.3.6.5 Radio priority 

If the UE supports A/Gb mode, the network may include this IE. 

8.3.6.6 Packet flow identifier 

If the UE supports A/Gb mode, the network may include this IE. If the UE indicated in the MS network capability it 
does not support BSS packet flow procedures, then the MME shall not include this IE. 

8.3.6.7 APN-AMBR 

This IE is included in the message when the network wishes to transmit the APN-AMBR to the UE for possible upUnk 
policy enforcement. 

8.3.6.8 ESM cause 

The network shall include this IE, if the network allocated a PDN address of a PDN type which is different from the 
PDN type requested by the UE. 

8.3.6.9 Protocol configuration options 

This IE is included in the message when the network wishes to transmit (protocol) data (e.g. configuration parameters, 
error codes or messages/events) to the UE. 

8.3.7 Bearer resource allocation reject 
8.3.7.1 Message definition 

This message is sent by the network to the UE to reject the allocation of a dedicated bearer resource. See table 8.3.7.1. 
Message type: BEARER RESOURCE ALLOCATION REJECT 
Significance: dual 
Direction: network to UE 



Table 8.3.7.1 : BEARER RESOURCE ALLOCATION REJECT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Bearer resource allocation reject 
message identity 


Message type 
9.8 


M 


V 


1 




ESM cause 


ESM cause 
9.9.4.4 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.7.2 Protocol configuration options 

This IE is included in the message when the network wishes to transmit (protocol) data (e.g. configuration parameters, 
error codes or messages/events) to the UE. 
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8.3.8 Bearer resource allocation request 
8.3.8.1 Message definition 

This message is sent by the UE to the network to request the allocation of a dedicated bearer resource. See table 8.3.8.1. 
Message type: BEARER RESOURCE ALLOCATION REQUEST 
Significance: dual 
Direction: UE to network 



Table 8.3.8.1 : BEARER RESOURCE ALLOCATION REQUEST message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer Identity 


EPS bearer identity 
9.3.2 


IVI 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Bearer resource allocation 
request message identity 


IVIessage type 
9.8 


M 


V 


1 




Linked EPS bearer identity 


Linl<ed EPS bearer identity 
9.9.4.6 


M 


V 


1/2 




Spare half octet 


Spare half octet 
9.9.2.9 


M 


V 


1/2 




Traffic flow aggregate 


Traffic flow aggregate description 
9.9.4.15 


M 


LV 


2-256 




Required traffic flow QoS 


EPS quality of service 
9.9.4.3 


M 


LV 


2-10 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.8.2 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 

8.3.9 Bearer resource modification reject 
8.3.9.1 Message definition 

This message is sent by the network to the UE to reject the modification of a dedicated bearer resource. See 
table 8.3.9.1. 

Message type: BEARER RESOURCE MODIFICATION REJECT 
Significance: dual 
Direction: network to UE 
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Table 8.3.9.1: BEARER RESOURCE MODIFICATION REJECT message content 





inTOiiTiaiion ciciTicni 


1 ype/rfeference 




ruriTiai 






Protocol discriminator 


Protocol discriminator 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 

Q Q 9 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Bearer resource modification 
reject message identity 


Message type 
9.8 


M 


V 


1 




ESIVI cause 


ESM cause 
9.9.4.4 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.9.2 Protocol configuration options 

This IE is included in the message when the network wishes to transmit (protocol) data (e.g. configuration parameters, 
error codes or messages/events) to the UE. 

8.3.10 Bearer resource modification request 

8.3.10.1 Message definition 

This message is sent by the UE to the network to request the modification of a dedicated bearer resource. See 
table 8.3.10.1. 

Message type: BEARER RESOURCE MODIFICATION REQUEST 
Significance: dual 
Direction: UE to network 



Table 8.3.10.1: BEARER RESOURCE MODIFICATION REQUEST message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Bearer resource modification 

request message Identity 


Message type 
9.8 


M 


V 


1 




EPS bearer Identity for packet 
filter 


Linked EPS bearer Identity 
9.9.4.6 


M 


V 


1/2 




Spare half octet 


Spare fialf octet 
9.9.2.9 


M 


V 


1/2 




Traffic flow aggregate 


Traffic flow aggregate description 
9.9.4.15 


M 


LV 


2-256 


5B 


Required traffic flow QoS 


EPS quality of service 
9.9.4.3 





TLV 


3-11 


58 


ESM cause 


ESM cause 
9.9.4.4 





TV 


2 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3. 1 0.2 Required traffic flow QoS 

This IE is included in the message when the UE requests a change of QoS for the indicated traffic flows. 
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8.3.10.3 ESM cause 

This IE is included in the message when the UE requests the release of a dedicated bearer resource. 

8.3.10.4 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 

8.3.1 1 Deactivate EPS bearer context accept 
8.3.1 1 .1 Message definition 

This message is sent by the UE to acknowledge deactivation of the EPS bearer context requested in the corresponding 
Deactivate EPS bearer context request message. See table 8.3. 11.1. 

Message type: DEACTIVATE EPS BEARER CONTEXT ACCEPT 

Significance: dual 

Direction: UE to network 



Table 8.3.11.1: DEACTIVATE EPS BEARER CONTEXT ACCEPT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Deactivate EPS bearer context 
accept message identity 


Message type 
9.8 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.1 1 .2 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration pjirameters, error 
codes or messages/events) to the network. 

8.3.12 Deactivate EPS bearer context request 
8.3.12.1 Message definition 

This message is sent by the network to request deactivation of an active EPS bearer context. See table 8.3.12.1. 
Message type: DEACTIVATE EPS BEARER CONTEXT REQUEST 
Significance: dual 
Direction: network to UE 
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Table 8.3.12.1: DEACTIVATE EPS BEARER CONTEXT REQUEST message content 





iniorniaiion cicincni 


1 ype/rieierence 




ruriTiai 






Protocol discriminator 


Protocol discriminator 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 

Q Q 9 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Deactivate EPS bearer context 
request message identity 


Message type 
9.8 


M 


V 


1 




ESIVI cause 


ESM cause 
9.9.4.4 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.12.2 Protocol configuration options 

This IE is included in the message when the network wishes to transmit (protocol) data (e.g. configuration parameters, 
error codes or messages/events) to the UE. 

8.3.13 ESM information request 

This message is sent by the network to the UE to request the UE to provide ESM information, i.e. protocol 
configuration options or APN or both. See table 8.3.13.1. 

Message type: ESM INFORMATION REQUEST 

Significance: dual 

Direction: network to UE 



Table 8.3.13.1: ESM INFORMATION REQUEST message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction Identity 


Procedure transaction identity 
9.4 


M 


V 


1 




ESM information request 
message identity 


Message type 
9.8 


M 


V 


1 



8.3.14 ESM information response 
8.3.14.1 Message definition 

This message is sent by the UE to the network in response to an ESM INFORMATION REQUEST message and 
provides the requested ESM information. See table 8.3.14.1. 

Message type: ESM INFORMATION RESPONSE 

Significance: dual 

Direction: UE to network 
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Table 8.3.14.1: ESM INFORMATION RESPONSE message content 





inTOiiTiaiion ciciTicni 


1 ype/rieierence 




ruriTiai 






Protocol discriminator 


Protocol discriminator 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 

Q Q 9 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




ESIVI information response 
message identity 


Message type 
9.8 


M 


V 


1 


28 


Access point name 


Access point name 
9.9.4.1 





TLV 


3-102 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.14.2 Access point name 

This IE is included in the message when the UE wishes to request network connectivity as defined by a certain access 
point name during the attach procedure. 

8.3.14.3 Protocol configuration options 

This IE is included in the message when, during the attach procedure, the UE wishes to transmit security protected 
(protocol) data (e.g. configuration parameters, error codes or messages/events) to the network. 

8.3.15 ESM status 

This message is sent by the network or the UE to pass information on the status of the indicated EPS bearer context and 
report certain error conditions (e.g. as Usted in clause 7). See table 8.3.15.1. 

Message type: ESM STATUS 

Significance: dual 

Direction: both 



Table 8.3.15.1 : ESM STATUS message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




ESM status message identity 


Message type 
9.8 


M 


V 


1 




ESM cause 


ESM cause 
9.9.4.4 


M 


V 


1 



8.3.16 Modify EPS bearer context accept 
8.3.16.1 Message definition 

This message is sent by the UE to the network to acknowledge the modification of an active EPS bearer context. See 
table 8.3.16.1. 

Message type: MODIFY EPS BEARER CONTEXT ACCEPT 
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Significance: dual 
Direction: UE to network 



Table 8.3.16.1: MODIFY EPS BEARER CONTEXT ACCEPT message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Modify EPS bearer context accept 
message identity 


Message type 
9.8 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.16.2 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 

8.3.17 Modify EPS bearer context reject 
8.3.17.1 Message definition 

This message is sent by the UE or the network to reject a modification of an active EPS bearer context. See 
table 8.3.17.1. 

Message type: MODIFY EPS BEARER CONTEXT REJECT 
Significance: dual 
Direction: UE to network 



Table 8.3.17.1: MODIFY EPS BEARER CONTEXT REJECT message content 



iEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction Identity 
9.4 


M 


V 


1 




Modify EPS bearer context reject 
message identity 


Message type 
9.8 


M 


V 


1 




ESM cause 


ESM cause 
9.9.4.4 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3. 1 7.2 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 
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8.3.18 Modify EPS bearer context request 
8.3.18.1 Message definition 

This message is sent by the network to the UE to request modification of an active EPS bearer context. See 
table 8.3.18.1. 

Message type: MODIFY EPS BEARER CONTEXT REQUEST 
Significance: dual 
Direction: network to UE 



Table 8.3.18.1: MODIFY EPS BEARER CONTEXT REQUEST message content 





inTorfnaiion cienrieni 


1 ype/Keierence 


Kresence 


rOrmai 


Lengin 




Protocol discriminator 


Protocol discriminator 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




Modify EPS bearer context 
request message identity 


Message type 
9.8 


M 


V 


1 


5B 


New EPS QoS 


EPS quality of service 
9.9.4.3 


Q 


TLV 


3-11 


36 


TFT 


Traffic flow template 
9.9.4.16 





TLV 


3-257 


30 


New QoS 


Quality of service 
9.9.4.12 


Q 


TLV 


14-18 


32 


Negotiated LLC SAPI 


LLC service access point identifier 
9.9.4.7 


Q 


TV 


2 


8- 


Radio priority 


Radio priority 
9.9.4.13 





TV 


1 


34 


Packet flow Identifier 


Packet flow Identifier 
9.9.4.8 





TLV 


3 


5E 


APN-AMBR 


APN aggregate maximum bit rate 
9.9.4.2 


Q 


TLV 


4-8 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.18.2 New EPS QoS 

When the EPS QoS of the EPS bearer context is modified, the network shall include the modified EPS QoS assigned to 
the EPS bearer context. 

8.3.18.3 TFT 

This IE provides the UE with packet filters. 

8.3.18.4 New QoS 

If the UE supports A/Gb mode or lu mode or both and when the corresponding pre-Rel-8 QoS of the EPS bearer context 
is modified, the network may include the corresponding pre-Rel-8 QoS parameter values of a PDP context. 

8.3.1 8.5 Negotiated LLC SAPI 

If the UE supports A/Gb mode and when the negotiated LLC SAPI is modified, the network may include this IE. 
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8.3.18.6 Radio priority 

If the UE supports A/Gb mode and when the radio priority is modified, the network may include this IE. 

8.3.18.7 Packet flow identifier 

If the UE supports A/Gb mode, the network may include this IE. If the UE indicated in the MS network capability it 
does not support BSS packet flow procedures, then the MME shall not include this IE. 

8.3.18.8 APN-AMBR 

This IE is included when the APN-AMBR has been changed by the network. 

8.3.18.9 Protocol configuration options 

This IE is included in the message when the network wishes to transmit (protocol) data (e.g. configuration parameters, 
error codes or messages/events) to the UE. 

8.3.19 PDN connectivity reject 
8.3.19.1 Message definition 

This message is sent by the network to the UE to reject establishment of a PDN cormection. See table 8.3.19.1. 
Message type: PDN CONNECTIVITY REJECT 
Significance: dual 
Direction: network to UE 



Table 8.3.19.1: PDN CONNECTIVITY REJECT message content 



lEI 


Information Eiement 


Type/Reference 


Presence 


Format 


Lengtii 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer Identity 


EPS bearer Identity 
9.3.2 


M 


V 


1/2 




Procedure transaction Identity 


Procedure transaction Identity 
9.4 


M 


V 


1 




PDN connectivity reject message 
Identity 


Message type 
9.8 


M 


V 


1 




ESM cause 


ESM cause 
9.9.4.4 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.1 9.2 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 

8.3.20 PDN connectivity request 
8.3.20.1 Message definition 

This message is sent by the UE to the network to initiate establishment of a PDN connection. See table 8.3.20.1. 
Message type: PDN CONNECTIVITY REQUEST 
Significance: dual 
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Direction: UE to network 



Table 8.3.20.1 : PDN CONNECTIVITY REQUEST message content 



lEI 


information Eiement 


Type/Reference 


Presence 


Format 


Lengtii 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




PDN connectivity request 
message identity 


Message type 
9.8 


M 


V 


1 




Request type 


Request type 
9.9.4.14 


M 


V 


1/2 




PDN type 


PDN type 
9.9.4.10 


M 


V 


1/2 


D- 


ESM information transfer flag 


ESM information transfer flag 
9.9.4.5 





TV 


1 


28 


Access point name 


Access point name 
9.9.4.1 





TLV 


3-102 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.20.2 ESM information transfer flag 

The UE shall include this IE in the PDN CONNECTIVITY REQUEST message sent during the attach procedure if the 
UE has protocol configuration options that need to be transferred security protected or wishes to provide an access point 
name for the PDN connection to be established during the attach procedure. 

8.3.20.3 Access point name 

This IE is included in the message when the UE wishes to request network connectivity as defined by a certain access 
point name. This IE shall not be included when the PDN CONNECTIVITY REQUEST message is included in an 
ATTACH REQUEST message. 

8.3.20.4 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 

8.3.21 PDN disconnect reject 
8.3.21 .1 Message definition 

This message is sent by the network to the UE to reject release of a PDN connection. See table 8.3.21.1. 
Message type: PDN DISCONNECT REJECT 
Significance: dual 
Direction: network to UE 
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Table 8.3.21.1: PDN DISCONNECT REJECT message content 





inTOiiTiaiion ciciTicni 


1 ype/rieierence 




ruriTiai 






Protocol discriminator 


Protocol discriminator 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 

Q Q 9 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


M 


V 


1 




PDN disconnect reject message 
identity 


Message type 
9.8 


M 


V 


1 




ESIVI cause 


ESM cause 
9.9.4.4 


M 


V 


1 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.21 .2 Protocol configuration options 

This IE is included in the message when the network wishes to transmit (protocol) data (e.g. configuration parameters, 
error codes or messages/events) to the UE. 

8.3.22 PDN disconnect request 

8.3.22.1 Message definition 

This message is sent by the UE to the network to initiate release of a PDN connection. See table 8.3.22.1. 
Message type: PDN DISCONNECT REQUEST 
Significance: dual 
Direction: UE to network 



Table 8.3.22.1: PDN DISCONNECT REQUEST message content 



lEI 


Information Element 


Type/Reference 


Presence 


Format 


Length 




Protocol discriminator 


Protocol discriminator 
9.2 


M 


V 


1/2 




EPS bearer identity 


EPS bearer identity 
9.3.2 


M 


V 


1/2 




Procedure transaction identity 


Procedure transaction identity 
9.4 


IVl 


V 


1 




PDN disconnect request message 
identity 


IVlessage type 
9.8 


M 


V 


1 




Linked EPS bearer identity 


Linl<ed EPS bearer identity 
9.9.4.6 


M 


V 


1/2 




Spare half octet 


Spare fialf octet 
9.9.2.9 


M 


V 


1/2 


27 


Protocol configuration options 


Protocol configuration options 
9.9.4.11 





TLV 


3-253 



8.3.22.2 Protocol configuration options 

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error 
codes or messages/events) to the network. 
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9 General message format and information elements 
coding 

9.1 Overview 

Within the protocols defined in the present document, every message, except the SERVICE REQUEST message, is a 
standard L3 message as defined in 3GPP TS 24.007 [12]. This means that the message consists of the following parts: 

1) if the message is a plain NAS message: 

a) protocol discriminator; 

b) EPS bearer identity or security header type; 

c) procedure transaction identity; 

d) message type; 

e) other information elements, as required. 

2) if the message is a security protected NAS message: 

a) protocol discriminator; 

b) security header type; 

c) message authentication code; 

d) sequence number; 

e) plain NAS message, as defined in item 1 . 

The organization of a plain NAS message is illustrated in the example shown in figure 9.1.1. 



EPS bearer identity 
or Security lieader type 



Protocol discriminator 



Procedure transaction identity 



Message type 



Other information elements as required 



octet 1 

octet 1 a* 
octet 2 
octet 3 

octet n 



Figure 9.1.1 : Generai message organization example for a plain NAS message 

The organization of a security protected NAS message is illustrated in the example shown in figure 9.1.2. 



8 



1 



Security header type 



Protocol discriminator 



Message authentication code 



Sequence number 



NAS message 



octet 1 
octet 2 



octet 5 
octet 6 
octet 7 

octet n 



Figure 9.1.2: General message organization example for a security protected NAS message 
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The EPS bearer identity and the procedure transaction identity are only used in messages with protocol discriminator 
EPS session management. Octet la with the procedure transaction identity shall only be included in these messages. 

Unless specified otherwise in the message descriptions of clause 8, a particular information element shall not be present 
more than once in a given message. 

When a field extends over more than one octet, the order of bit values progressively decreases as the octet number 
increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet 
of the field. 



9.2 Protocol discriminator 

The Protocol Discriminator (PD) and its use are defined in 3GPP TS 24.007 [12]. The protocol discriminator in the 
header (see 3GPP TS 24.007 [12]) of a secmty protected NAS message is encoded as "EPS mobility management 
messages". 

9.3 Security header type and EPS bearer identity 
9.3.1 Security header type 

Bits 5 to 8 of the first octet of every EPS Mobility Management (EMM) message contain the Security header type IE. 
This IE includes control information related to the security protection of a NAS message. The total size of the Security 
header type IE is 4 bits. 

The Security header type IE can take the values shown in table 9.3.1. 



Table 9.3.1 : Security header type 



Security header type (octet 1 ) 



8 


7 


6 


5 
















Plain NAS message, not security protected 










Security protected NAS message: 











1 


Integrity protected 








1 





Integrity protected and ciphered 








1 


1 


Integrity protected with new EPS security context (NOTE 1) 





1 








Integrity protected and ciphered with new EPS security context (NOTE 2) 










Non-standard L3 message: 


1 


1 








Security header for the SERVICE REQUEST message 


1 


1 





1 


These values are not used in this version of the protocol. 




to 




If received they shall be interpreted as "11 00". (NOTE 3) 


1 


1 


1 


1 





All other values are reserved. 



NOTE 1 : This codepoint may be used only for a SECURITY MODE COMMAND 

message. 

NOTE 2: This codepoint may be used only for a SECURITY MODE COMPLETE 
message. 

NOTE 3: When bits 7 and 8 are set to '1 1 ', bits 5 and 6 can be used for future 
extensions of the SERVICE REQUEST message. 



An EMM message received with the security header type encoded as 0000 shall be treated as not security protected, 
plain NAS message. A protocol entity sending a not security protected EMM message shall send the message as plain 
NAS message and encode the security header type as 0000. 
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9.3.2 EPS bearer identity 

Bits 5 to 8 of the first octet of every EPS Session Management (ESM) message contain the EPS bearer identity. The 
EPS bearer identity and its use to identify a message flow are defined in 3GPP TS 24.007 [12]. 

9.4 Procedure transaction identity 

Bits 1 to 8 of the second octet (octet la) of every EPS Session Management (ESM) message contain the procedure 
transaction identity. The procedure transaction identity and its use are defined in 3GPP TS 24.007 [12]. 

9.5 Message authentication code 

The Message authentication code (MAC) information element contains the integrity protection information for the 
message. The MAC IE shall be included in the security protected NAS message if a valid NAS security context exists 
and security functions are started. The usage of MAC is specified in subclause 4.4.3.3. 

9.6 Sequence number 

This IE includes the NAS message sequence number (SN) which consists of the eight least significant bits of the NAS 
COUNT for a security protected NAS message The usage of SN is specified in subclause 4.4.3. 

9.7 NAS message 

This IE includes a complete plain NAS message as specified in subclause 8.2 and 8.3. The SECURITY PROTECTED 
NAS MESSAGE and the SERVICE REQUEST message are not plain NAS messages and shall not be included in this 
IE. 

9.8 IVIessage type 

The message type IE and its use are defined in 3GPP TS 24.007 [12]. Tables 9.8.1 and 9.8.2 define the value part of the 
message type IE used in the EPS mobility management protocol and EPS session management protocol. 
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Table 9.8.1 : Message types for EPS mobility management 

Bits 



8 


7 


6 


5 


4 


3 


2 


1 







1 














EPS mobility management messages 





1 

















1 


Attach request 





1 














1 





Attach accept 





1 














1 


1 


Attach complete 





1 











1 








Attach reject 





1 











1 





1 


Detach request 





1 











1 


1 





Detach accept 





1 








1 











Tracking area update request 





1 








1 








1 


Tracking area update accept 





1 








1 





1 





Tracking area update complete 





1 








1 





1 


1 


Tracking area update reject 





1 








1 


1 








Extended service request 





1 








1 


1 


1 





Service reject 





1 





1 














GUTI reallocation command 





1 





1 











1 


GUTI reallocation complete 





1 





1 








1 





Authentication request 





1 





1 








1 


1 


Authentication response 





1 





1 





1 








Authentication reject 





1 





1 


1 


1 








Authentication failure 





1 





1 





1 





1 


Identity request 





1 





1 





1 


1 





Identity response 





1 





1 


1 


1 





1 


Security mode command 





1 





1 


1 


1 


1 





Security mode complete 





1 





1 


1 


1 


1 


1 


Security mode reject 





1 


1 

















EMM status 





1 


1 














1 


EMM information 





1 


1 











1 





Downlink NAS transport 





1 


1 











1 


1 


Uplink NAS transport 





1 


1 








1 








CS Service notification 
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Table 9.8.2: Message types for EPS session management 



Bits 
















8 7 


6 


5 


4 


3 


2 


1 




1 1 














EPS ssssion manaaement msssaass 

1— 1 O w wO 1 V 1 III ICLt lUu w 1 1 1 wl 1 L II 1 wOOUU w w 


1 1 

















1 


Activate default EPS bearer context request 


1 1 














1 





Activate default EPS bearer context accept 


1 1 














1 


1 


Activate default EPS bearer context reject 


1 1 











1 





1 


Activate dedicated EPS bearer context request 


1 1 











1 


1 





Activate dedicated EPS bearer context accept 


1 1 











1 


1 


1 


Activate dedicated EPS bearer context reject 


1 1 








1 








1 


IVIodify EPS bearer context request 


1 1 








1 





1 





IVIodify EPS bearer context accept 


1 1 








1 





1 


1 


IVIodify EPS bearer context reject 


1 1 








1 


1 





1 


Deactivate EPS bearer context request 


1 1 








1 


1 


1 





Deactivate EPS bearer context accept 


1 1 





1 














PDN connectivity request 


1 1 





1 











1 


PDN connectivity reject 


1 1 





1 








1 





PDN disconnect request 


1 1 





1 








1 


1 


PDN disconnect reject 


1 1 





1 





1 








Bearer resource allocation request 


1 1 





1 





1 





1 


Bearer resource allocation reject 


1 1 





1 





1 


1 





Bearer resource modification request 


1 1 





1 





1 


1 


1 


Bearer resource modification reject 


1 1 





1 


1 








1 


ESM information request 


1 1 





1 


1 





1 





ESM information response 


1 1 


1 





1 











ESM status 



9.9 Other information elements 
9.9.1 General 

The different formats (V, LV, T, TV, TLV, TLV-E) and the five categories of information elements (type 1, 2, 3, 4 and 
6) are defined in 3GPP TS 24.007 [12]. 

The first octet of an information element in the non-imperative part contains the lEI of the information element. If this 
octet does not correspond to an lEI known in the message, the receiver shall determine whether this IE is of type 1 or 2 
(i.e. it is an information element of one octet length) or an IE of type 4 (i.e. that the next octet is the length indicator 
indicating the length of the remaining of the information element) (see 3GPP TS 24.007 [12]). 

This allows the receiver to jump over unknown information elements and to analyse any following information 
elements. 

The definitions of information elements which are common for the EMM and ESM protocols or which are used by 
access stratum protocols are described in subclause 9.9.2. 

The information elements of the EMM or ESM protocols can be defined by reference to an appropriate specification, 
e.g., "see subclause 10.5.6.3 in 3GPP TS 24.008 [13]". 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 181 ETSI TS 124 301 V8.2.1 (2009-06) 

9.9.2 Common information elements 
9.9.2.1 EPS bearer context status 

The purpose of the EPS bearer context status information element is to indicate the state of each EPS bearer context that 

can be identified by an EPS bearer identity. 

The EPS bearer context status information element is coded as shown in figure 9.9.2.1.1 and table 9.9.2.1.1. 
The EPS bearer context status information element is a type 4 information element with 4 octets length. 



8 


7 


6 


5 


4 


3 


2 


1 




EPS bearer context status lEI 


octet 1 


Length of EPS bearer context status contents 


octet 2 


EBI 


EBI 


EBI 


EBI 


EBI 


EBI 


EBI 


EBI 


octet 3 


(7) 


(6) 


(5) 


(4) 


(3) 


(2) 


(1) 


(0) 




EBI 


EBI 


EBI 


EBI 


EBI 


EBI 


EBI 


EBI 


octet 4 


(15) 


(14) 


(13) 


(12) 


(11) 


(10) 


(9) 


(8) 





Figure 9.9.2.1.1 : EPS bearer context status information element 



Table 9.9.2.1.1: EPS bearer context status information element 



EBI(x) shall be coded as follows: 
EBI(O) - EBI(4): 

Bits to 4 of octet 3 are spare and shall be coded as zero. 

EBI(5)-EBI(15): 

indicates that the ESIVI state of the corresponding EPS bearer context is BEARER CONTEXT-INACTIVE. 

1 indicates that the ESM state of the corresponding EPS bearer context is BEARER CONTEXT-ACTIVE. 



9.9.2.2 Location area identification 

See subclause 10.5.1.3 in 3GPP TS 24.008 [13]. 

9.9.2.3 Mobile identity 

See subclause 10.5.1.4 in 3GPP TS 24.008 [13]. 

9.9.2.4 Mobile station classmark 2 

See subclause 10.5.1.6 in 3GPP TS 24.008 [13]. 

9.9.2.5 Mobile station classmark 3 

See subclause 10.5.1.7 in 3GPP TS 24.008 [13]. 

9.9.2.6 NAS security parameters from E-UTRA 

The purpose of the NAS security parameters from E-UTRA information element is to provide the UE with information 
that enables the UE to create a mapped UMTS security context. 

The NAS security parameters from E-UTRA information element is coded as shown in figure 9.9.2.6.1 and 
table 9.9.2.6.1. 

The NAS security parameters from E-UTRA is a type 3 information element with a length of 2 octets. 
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The value part of the NAS security parameters from E-UTRA information element is included in specific information 
elements within some RRC messages sent to the UE; see 3GPP TS 36.331 [22]. For these cases the coding of the 
information element identifier and length information is defined in 3GPP TS 36.331 [22]. 



8 7 6 5 4 3 2 1 



NAS security parameters to E-UTRA lEI 


octet 1 








DL NAS COUNT value 






Spare 


(short) 


octet 2 



Figure 9.9.2.6.1 : NAS security parameters from E-UTRA information element 



Table 9.9.2.6.1 : NAS security parameters from E-UTRA information element 



DL NAS COUNT value (short) (octet 2, bit 1 to 4) 

This field contains the 4 least significant bits of the binary representation of the 
downlink NAS COUNT value applicable when this information element is sent. 



9.9.2.7 NAS security parameters to E-UTRA 

The purpose of the NAS security parameters to E-UTRA information element is to provide the UE with parameters that 
enable the UE to create a mapped EPS security context and take this context into use after inter-system handover to SI 
mode. 

The NAS security parameters to E-UTRA information element is coded as shown in figure 9.9.2.7.1 and table 9.9.2.7.1. 

The NAS security parameters to E-UTRA is a type 3 information element with a length of 7 octets. 

The value part of the NAS security parameters to E-UTRA information element is included in specific information 
elements within some RRC messages sent to the UE; see 3GPP TS 36.331 [22]. For these cases the coding of the 
information element identifier and length information is defined in 3GPP TS 36.331 [22]. 



8 7 6 5 4 3 2 1 



NAS security parameters to E-UTRA IE! 


octet 1 
octet 2 

octet 5 


NonceMME value 


Type of ciphering 
spare algorithm 




spare 


Type of integrity 
protection algorithm 


octet 6 




spare 


TSC 


NAS key set identifier 


octet 7 



Figure 9.9.2.7.1 : NAS security parameters to E-UTRA information element 
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Table 9.9.2.7.1 : NAS security parameters to E-UTRA information element 



NonceMME value (octet 2 to 5) 

This field is coded as the nonce value in the Nonce information element (see 
subclause 9.9.3.25). 

Type of integrity protection algorithm (octet 6, bit 1 to 3) and 
type of ciphering algorithm (octet 6, bit 5 to 7) 

These fields are coded as the type of integrity protection algorithm and type of 
ciphering algorithm in the NAS security algorithms information element (see subclause 
9.9.3.23). 

Bit 4 and 8 of octet 6 are spare and shall be coded as zero. 

NAS key set identifier (octet 7, bit 1 to 3) and 
type of security context flag (TSC) (octet 7, bit 4) 

These fields are coded as the NAS key set identifier and type of security context flag in 
the NAS key set identifier information element (see subclause 9.9.3.21). 

Bit 5 to 8 of octet 7 are spare and shall be coded as zero. 



9.9.2.8 PLMN list 

See subclause 10.5.1.13 in 3GPP TS 24.008 [IBJ. 

9.9.2.9 Spare half octet 

This element is used in the description of EMM and ESM messages when an odd number of half octet type 1 
information elements are used. This element is filled with spare bits set to zero and is placed in bits 5 to 8 of the octet 
unless otherwise specified. 

9.9.2.10 Supported codec list 

See subclause 10.5.4.32 in 3GPP TS 24.008 [13]. 

9.9.3 EPS Mobility Management (EMM) information elements 

9.9.3.1 Authentication failure parameter 

See subclause 10.5.3.2.2 in 3GPP TS 24.008 [13]. 

9.9.3.2 Authentication parameter AUTN 

See subclause 10.5.3.1.1 in 3GPP TS 24.008 [13J. 

9.9.3.3 Authentication parameter RAND 

See subclause 10.5.3.1 in 3GPP TS 24.008 [13]. 

9.9.3.4 Authentication response parameter 

The purpose of the Authentication response parameter information element is to provide the network with the 
authentication response calculated in the USIM. 

The Authentication response parameter information element is coded as shown in figure 9.9.3.4.1 and table 9.9.3.4.1. 
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The Authentication response parameter is a type 4 information element with a minimum length of 6 octets and a 

maximum length of 18 octets. 

In an EPS authentication challenge, the response calculated in the USIM (RES) is minimum 4 octets and may be up to 
16 octets in length. 



8 7 6 5 4 3 2 1 

octet 1 
octet 2 
octet 3 

octet 18 

Figure 9.9.3.4.1: Autlientication response parameter information element 

Table 9.9.3.4.1 : Authentication response parameter information element 

RES value (octet 3 to 1 8) 
This contains tlie RES. 

9.9.3.4A Ciphering key sequence number 

See subclause 9.9.3.19 in 3GPP TS 24.008 [13]. 

9.9.3.5 CSFB response 

The piupose of the CSFB response information element is to indicate whether the UE accepts or rejects a paging for CS 

fallback. 

The CSFB response information element is coded as shown in figure 9.9.3.5.1 and table 9.9.3.5.1. 
The CSFB response is a type 1 infornoation element. 



8 7 6 5 


4 


3 2 1 


CSFB response 





CSFB response value 


lEI 


spare 





Figure 9.9.3.5.1 : CSFB response information element 

Table 9.9.3.5.1 : CSFB response information element 

CSFB response value (octet 1 ) 
Bits 

3 2 1 

CS fallback rejected by the UE 
1 CS fallback accepted by the UE 

All other values are reserved. 



Authentication response parameter IE! 



Length of Authentication response parameter contents 




9.9.3.6 Dayliglit saving time 

See subclause 10.5.3.12 in 3GPP TS 24.008 [13]. 
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9.9.3.7 Detach type 

The purpose of the Detach type information element is to indicate the type of detach. 

The Detach type information element is coded as shown in figure 9.9.3.7.1 and table 9.9.3.7.1. 

The Detach type is a type 1 information element. 



8 


7 6 


5 


4 


3 


2 1 




Detach type 
lEI 


Switch 
off 


Type of detach 


octet 1 



Figure 9.9.3.7.1 : Detach type information element 



Table 9.9.3.7.1 : Detach type information element 

Type of detach (octet 1 ) 

In the UE to network direction: 



Bits 






3 2 


1 







1 


EPS detach 


1 





IMSI detach 


1 


1 


combined EPS/IMSI detach 


1 1 





reserved 


1 1 


1 


reserved 



All other values are interpreted as "combined EPS/IMSI detach" in this version of the 
protocol. 

In the network to UE direction: 



Bits 






3 2 


1 







1 


re-attach required 


1 





re-attach not required 


1 


1 


IMSI detach 


1 1 





reserved 


1 1 


1 


reserved 



All other values are interpreted as "re-attach not required" in this version of the 
protocol. 

Switch off (octet 1) 

In the UE to network direction: 

Bit 

4 

normal detach 

1 switch off 

In the network to UE direction bit 4 is spare. The network shall set this bit to zero. 



9.9.3.8 DRX parameter 

See subclause 10.5.5.6 in 3GPP TS 24.008 [13]. 

9.9.3.9 EMM cause 

The purpose of the EMM cause information element is to indicate the reason why an EMM request from the UE is 
rejected by the network. 

The EMM cause information element is coded as shown in figure 9.9.3.9.1 and table 9.9.3.9.1. 
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EMM cause lEI 



Cause value 



octet 1 
octet 2 



Figure 9.9.3.9.1 : ElUIIUI cause information element 



Table 9.9.3.9.1 : EMM cause information element 



Cause value (octet 2) 



Bits 
















8 


7 


6 


5 


4 


3 


2 


1 






















1 





IMSI unknown in HSS 




















1 


1 


Illegal UE 

















1 


1 





Illegal ME 

















1 


1 


1 


EPS services not allowed 














1 











EPS services and non-EPS services not allowed 














1 








1 


UE identity cannot be derived by the network 














1 





1 





Implicitly detached 














1 





1 


1 


PLMN not allowed 














1 


1 








Tracking Area not allowed 














1 


1 





1 


Roaming not allowed In this tracking area 














1 


1 


1 





EPS services not allowed in this PLMN 














1 


1 


1 


1 


No Suitable Cells In tracking area 











1 














MSC temporarily not reachable 











1 











1 


Network failure 











1 








1 





CS domain not available 











1 








1 


1 


ESM failure 











1 





1 








MAC failure 











1 





1 





1 


Synch failure 











1 





1 


1 





Congestion 











1 





1 


1 


1 


UE security capabilities mismatch 











1 


1 











Security mode rejected, unspecified 











1 


1 








1 


Not authorized for this CSG 











1 


1 





1 





Non-EPS authentication unacceptable 








1 








1 


1 


1 


CS domain temporarily not available 








1 





1 











No EPS bearer context activated 





1 





1 


1 


1 


1 


1 


Semantically incorrect message 





1 


1 

















Invalid mandatory information 





1 


1 














1 


Message type non-existent or not implemented 





1 


1 











1 





Message type not compatible with the protocol 
state 





1 


1 











1 


1 


Information element non-existent or not 
implemented 





1 


1 








1 








Conditional IE error 





1 


1 








1 





1 


Message not compatible with the protocol state 





1 


1 





1 


1 


1 


1 


Protocol error, unspecified 



Any other value received by the mobile station shall be treated as 01 10 1 1 1 1 , "Protocol 
error, unspecified". Any other value received by the network shall be treated as 01 10 
1111, "Protocol error, unspecified". 



9.9.3.10 EPS attach result 

The purpose of the EPS attach result information element is to specify the result of an attach procedure. 
The EPS attach result information element is coded as shown in figure 9.9.3.10.1 and table 9.9.3.10.1. 
The EPS attach result is a type 1 information element. 
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8 7 6 5 4 3 2 1 



EPS attach result lEI 





EPS attach result value 




Spare 





Figure 9.9.3.10.1: EPS attach result information element 
Table 9.9.3.10.1: EPS attach result information element 



EPS attach result value (octet 1) 
Bits 

3 2 1 

1 EPS only 

1 combined EPS/IMSI attach 

All other values are reserved. 

Bit 4 of octet 1 is spare and shall be coded as zero. 



9.9.3.11 EPS attach type 

The purpose of the EPS attach type information element is to indicate the type of the requested attach. 
The EPS attach type information element is coded as shown in figure 9.9.3.11.1 and table 9.9.3.11.1. 
The EPS attach type is a type 1 information element. 



EPS attach type lEI 





Spare 



3 2 1 

EPS attach type value 



octet 1 



Figure 9.9.3.11.1: EPS attach type Information element 
Table 9.9.3.11.1 : EPS attach type information element 



EPS attach type value (octet 1 ) 
Bits 

3 2 1 

1 EPS attach 

1 combined EPS/IMSI attach 

1 1 reserved 
1 1 1 reserved 

All other values are unused and shall be interpreted as "EPS attach", if received by the 
network. 

Bit 4 of octet 1 is spare and shall be coded as zero. 



9.9.3.12 EPS mobile identity 

The purpose of the EPS mobile identity information element is to provide either the IMSI or the GUTI. If the 
information element is sent by the UE and the UE has a valid GUTI, the EPS mobile identity is populated with the 
GUTI value. When the UE does not have a valid GUTI, the UE populates this IE with its IMSI value. 

The EPS mobile identity information element is coded as shown in figures 9.9.3.12.1 and 9.9.3.12.2 and 
table 9.9.3.12.1. 
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The EPS mobile identity is a type 4 information element with a minimum length of 3 octets and a maximum length of 
13 octets. 



EPS mobile identity lEI 



Lengtli of EPS mobile identity contents 



1 



1 



MCC digit 2 



MNC digit 3 



MNC digit 2 



odd/ 
even 
indie 



Type of identity 



MCC digit 1 



MCC digit 3 



MNC digit 1 



MME Group ID 



MME Group ID (continued) 



MME Code 



M-TMSI 



M-TMSI (continued) 



M-TMSI (continued) 



M-TMSI (continued) 



octet 1 
octet 2 
octet 3 

octet 4 
octet 5 
octet 6 
octet 7 
octet 8 
octet 9 
octet 1 
octet 1 1 
octet 12 
octet 13 



Figure 9.9.3.12.1 : EPS mobile identity information element for type of identity "GUTI" 



8 7 6 5 4 3 2 1 



EPS mobile identity lEI 


octet 1 


Length of EPS mobile identity contents 


octet 2 


Identity digit 1 


odd/ 
even 
indie 


Type of identity 


octet 3 


Identity digit p+1 


Identity digit p 


octet 4* 



Figure 9.9.3.12.2: EPS mobile identity information element for type of identity "IIUISI" 
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Table 9.9.3.12.1 : EPS mobile identity information element 



Type of identity (octet 3) 
Bits 

3 2 1 

1 IMSI 

1 1 GUTI 

All other values are reserved. 

Odd/even indication (octet 3) 

Bit 

4 

even number of identity digits and also when the GUTI is used 

1 odd number of identity digits 

Identity digits (octet 4 etc) 

For the IMSI, this field is coded using BCD coding. If the number of identity digits is 
even then bits 5 to 8 of the last octet shall be filled with an end mark coded as 
"1111". 

For the GUTI, then bits 5 to 8 of octet 3 are coded as "1111 ", octet 4 through 6 
contain the MCC and MNC values as specified below, and bit 8 of octet 7 is the 
most significant bit and bit 1 of the last octet the least significant bit for the 
subsequent fields. The required fields for the GUTI are as defined in 
3GPP TS 23.003 [2]. 

MCC, Mobile country code (octet 4, octet 5 bits 1 to 4) 

The MCC field is coded as in ITU-T Recommendation E.212 [30], annex A. 

MNC, Mobile network code (octet 5 bits 5 to 8, octet 6) 

The coding of this field is the responsibility of each administration but BCD coding 
shall be used. The MNC shall consist of 2 or 3 digits. If a network operator decides 
to use only two digits in the MNC, bits 5 to 8 of octet 5 shall be coded as "1111 ". 

The contents of the MCC and MNC digits are coded as octets 6 to 8 of the 
Temporary Mobile Group Identity IE in figure 10.5.154 of 3GPP TS 24.008 [13]. 



9.9.3.13 EPS update result 

The purpose of the EPS update result information element is to specify the result of the associated updating procedure. 
The EPS update type information element is coded as shown in figure 9.9.3.13.1 and table 9.9.3.13.1. 
The EPS update type is a type 1 information element. 



8 7 6 5 4 3 2 1 



EPS update result 





EPS update result 


octet 1 


lEI 


Spare 


value 





Figure 9.9.3.13.1: EPS update result information element 
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Table 9.9.3.13.1: EPS update result information element 



EPS update result value (octet 1 , bit 1 to 3) 


Bits 




3 2 1 







TA updated 


1 


combined TA/LA updated 


1 


TA updated and ISR activated (NOTE) 


1 1 


combined TA/LA updated and ISR activated (NOTE) 


All other values are reserved. 


Bit 4 of octet 1 is spare and shall be coded as zero. 


NOTE: 


Values 'TA updated and ISR activated' and 'combined TA/LA updated and 




ISR activated' are used only for a UE supporting also A/Gb or lu mode. 



9.9.3.14 EPS update type 

The purpose of the EPS update type iiiformation element is to specify the area the updating procedure is associated 
with. 

The ESP update type information element is coded as shown in figure 9.9.3.14.1 and table 9.9.3.14.1. 
The EPS update type is a type 1 information element. 



8 7 6 5 


4 


3 2 1 




EPS update type 


"Active" 


EPS update type 


octet 1 


lEI 


flag 


Value 





Figure 9.9.3.14.1: EPS update type information element 



Table 9.9.3.14.1 : EPS update type information element 



EPS update type value (octet 1 , bit 1 to 3) 


Bits 




3 2 1 







TA updating 


1 


combined TA/LA updating 


1 


combined TA/LA updating with IMSI attach 


1 1 


periodic updating 


1 


unused; shall be interpreted as "TA updating", if received by the network. 


1 1 


unused; shall be interpreted as "TA updating", if received by the network. 


All other values are reserved. 


"Active" flag (octet 1 , bit 4) 


Bit 
4 







No bearer establishment requested 


1 


Bearer establishment requested 



9.9.3.15 ESM message container 

The purpose of the ESM message container information element is to enable piggybacked transfer of a single ESM 
message within an EMM message. The ESM message included in this IE shall be coded as specified in subclause 8.3, 
i.e. without NAS security header. 
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The ESM message container information element is coded as shown in figure 9.9.3.15.1 and table 9.9.3.15.1. 
The ESM message container is a type 6 information element. 



ESM message container lEI 



Length of ESM message container contents 



ESM message container contents 



octet 1 
octet 2 
octet 3 
octet 4 

octet n 



Figure 9.9.3.15.1: ESM message container information element 
Table 9.9.3.15.1: ESM message container information element 



ESM message container contents (octet 4 to octet n) ; Max value of 65535 octets 
This IE can contain any ESM PDU as defined in subclause 8.3. 



9.9.3.16 GPRS timer 

See subclause 10.5.7.3 in 3GPP TS 24.008 [13]. 

9.9.3.17 Identity type 2 

See subclause 10.5.5.9 in 3GPP TS 24.008 [13]. 

9.9.3.18 IMEISV request 

See subclause 10.5.5.10 in 3GPP TS 24.008 [13]. 

9.9.3.19 KSI and sequence number 

The purpose of the KSI and sequence number information element is to provide the network with the key set identifier 
(KSI) value of the current EPS security context and the 5 least significant bits of the NAS COUNT value apphcable for 
the message including this information element. 

The KSI and sequence number information element is coded as shown in figure 9.9.3. 19.1 and table 9.9.3.19.1. 
The KSI and sequence number is a type 3 information element with a length of 2 octets. 



KSI and sequence number lEI 



octet 1 
octet 2 



KSI 



Sequence number (short) 



Figure 9.9.3.19.1: KSI and sequence number information element 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 



192 



ETSI TS 124 301 V8.2.1 (2009-06) 



Table 9.9.3.19.1: KSI and sequence number information element 



Sequence number (short) (octet 2, bit 1 to 5) 

This field contains the 5 least significant bits of the NAS COUNT value applicable when 
this message is sent. 

KSI (octet 2, bit 6 to 8) 

This field contains the key set identifier value, as specified in bit 1 to 3 of octet 1 of the 
NAS key set identifier information element, (see subclause 9.9.3.21.) 



9.9.3.20 MS network capability 

See subclause 10.5.5.12 in 3GPP TS 24.008 [13]. 

9.9.3.21 NAS key set identifier 

The NAS key set identifier is allocated by the network. 

The NAS key set identifier information element is coded as shown in figure 9.9.3.21.1 and table 9.9.3.21.1. 
The NAS key set identifier is a type 1 information element. 



8 



1 



NAS key set identifier lEI 



TSC NAS key set identifier octet 1 



Figure 9.9.3.21.1 : NAS key set identifier information element 
Table 9.9.3.21.1 : NAS key set identifier information element 



Type of security context flag (TSC) (octet 1) 

Bit 
4 

native security context (for KSIasme) 

1 mapped security context (for KSIsgsn) 

TSC does not apply for NAS key set identifier value "1 1 1 ". 

NAS key set identifier (octet 1 ) 

Bits 

3 2 1 



through possible values for the NAS key set identifier 

1 1 

1 1 1 no key is available 



9.9.3.22 NAS message container 

This information element is used to encapsulate the SMS messages transferred between the UE and the network.The 
NAS message container information element is coded as shown in figure 9.9.3.22.1 and table 9.9.3.22.1. 

The NAS message container is a type 4 information element with a minimum length of 4 octets and a maximum length 
of 253 octets. 
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NAS message container lEI 



octet 1 
octet 2 
octet 3 

octet n 



Length of NAS message container contents 



NAS message container contents 



Figure 9.9.3.22.1 : NAS message container information element 



Table 9.9.3.22.1: NAS message container information element 

NAS message container contents (octet 3 to octet n) 

This IE can contain an SIVIS message (i.e. CP-DATA, CP-ACK or CP-ERROR) as 
defined in subclause 7.2 in 3GPP TS 24.011 [13A]. 



9.9.3.23 NAS security algorithms 

The purpose of the NAS security algorithms information element is to indicate the algorithms to be used for ciphering 
and integrity protection. 

The NAS security algorithms information element is coded as shown in figure 9.9.3.23.1 and table 9.9.3.23.1. 
The NAS security algorithms is a type 3 information element with a length of 2 octets. 



8 7 6 5 4 3 2 1 



NAS security algorithms lEI 


octet 1 





Type of ciphering 





Type of Integrity 


octet 2 


spare 


algorithm 


spare 


protection algorithm 





Figure 9.9.3.23.1 : NAS security algoritlims information element 
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Table 9.9.3.23.1 : NAS security algorithms information element 



Type of integrity protection algoritlim (octet 2, bit 1 to 3) 


Bits 




3 2 1 







Reserved 


1 


EPS integrity algorithm 128-EIA1 


1 


EPS integrity algorithm 128-EIA2 


1 1 


EPS integrity algorithm EIA3 


1 


EPS integrity algorithm EIA4 


1 1 


EPS integrity algorithm EIA5 


1 1 


EPS integrity algorithm EIA6 


1 1 1 


EPS integrity algorithm EIA7 


Type of cipliering algorithm (octet 2, bit 5 to 7) 


Bits 




7 6 5 







EPS encryption algorithm EEAO (ciphering not used) 


1 


EPS encryption algorithm 128-EEA1 


1 


EPS encryption algorithm 128-EEA2 


1 1 


EPS encryption algorithm EEA3 


1 


EPS encryption algorithm EEA4 


1 1 


EPS encryption algorithm EEA5 


1 1 


EPS encryption algorithm EEA6 


1 1 1 


EPS encryption algorithm EEA7 


Bit 4 and 8 of octet 2 are spare and sfiall be coded as zero. 



9.9.3.24 Network name 

See subclause 10.5.3.5a in 3GPP TS 24.008 [13]. 

9.9.3.25 Nonce 

The purpose of the Nonce information element is to transfer a 32-bit nonce value to support deriving a new mapped 
EPS security context. 

The Nonce information element is coded as shown in figure 9.9.3.25.1 and table 9.9.3.25.1. 
The Nonce is a type 3 information element with a length of 5 octets. 



8 7 6 5 4 3 2 1 

Nonce lEI 



Nonce value 



Figure 9.9.3.25.1: Nonce information element 
Table 9.9.3.25.1 : Nonce information element 



Nonce value (octet 2 to 5) 

This field contains the binary representation of the nonce. Bit 8 of octet 2 represents 
the most significant bit of the nonce and bit 1 of octet 5 the least significant bit. 



9.9.3.25A Paging identity 

The purpose of the Paging identity information element is to indicate the identity used for paging for non-EPS services. 



octet 1 
octet 2 

octet 5 
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The Paging identity information element is coded as shown in figure 9.9. 3.25 A.l and table 9.9.3.25A.1. 
The Paging identity is a type 3 information element with 2 octets length. 
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Figure 9.9.3.25A.1 : Paging identity information element 



Table 9.9.3.25A.1 : Paging identity information element 



Paging identity value (octet 2) 

Bit 
1 

IIVISI 

1 TMSI 



9.9.3.26 P-TMSI signature 

See subclause 10.5.5.8 in 3GPP TS 24.008 L13]. 



9.9.3.27 Service type 

The purpose of the Service type information element is to specify the purpose of the service request procedure. 
The Service type information element is coded as shown in figure 9.9.3.27.1 and table 9.9.3.27.1. 
The Service type is a type 1 information element. 
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Figure 9.9.3.27.1 : Service type information element 



Table 9.9.3.27.1 : Service type information element 



Service type value (octet 1 ) 

Service type value 
Bits 

4 3 2 1 

mobile originating CS fallback or IxCS fallback 

1 mobile terminating CS fallback or IxCS fallback 

10 mobile originating CS fallback emergency call or IxCS fallback 

emergency call 

All other values are reserved. 



9.9.3.28 Sliort MAC 

The piupose of the Short MAC information element is to protect the integrity of a SERVICE REQUEST message. 
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The integrity protection shall include octet 1 and 2 of the SERVICE REQUEST message. For the used algorithm and 
other input parameters to the algorithm see subclause 9.5. Only the 2 least significant octets of the resulting message 
authentication code are included in the information element. 

The Short MAC information element is coded as shown in figure 9.9.3.28.1 and table 9.9.3.28.1. 
The Short MAC is a type 3 information element with a length of 3 octets. 
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Figure 9.9.3.28.1 : Short MAC information element 
Table 9.9.3.28.1 : Short MAC information element 



Short MAC value (octet 2 and 3) 

This field contains the 2 least significant octets of the message authentication code 
calculated for the SERVICE REQUEST message. Bit 1 of octet 3 contains the least 
significant bit, and bit 8 of octet 2 the most significant bit of these 2 octets. 



9.9.3.29 Time zone 

See subclause 10.5.3.8 in 3GPP TS 24.008 [13]. 

9.9.3.30 Time zone and time 

See subclause 10.5.3.9 in 3GPP TS 24.008 [13]. 

9.9.3.31 TMSI status 

See subclause 10.5.5.4 in 3GPP TS 24.008 [13]. 

9.9.3.32 Tracking area identity 

The purpose of the Tracking area identity information element is to provide an unambiguous identification of tracking 
areas within the area covered by the 3GPP system. 

The Tracking area identity information element is coded as shown in figure 9.9.3.32.1 and table 9.9.3.32.1. 
The Tracking area identity is a type 3 information element with a length of 6 octets. 
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Figure 9.9.3.32.1 : Tracking area identity information element 



Table 9.9.3.32.1 : Tracking area identity information element 



IVICC, IVIobile country code (octet 2 and 3) 

The MGG field is coded as in ITU-T Rec. E212, annex A. 

If the TAI is deleted the MGG and MNG shall take the value from the deleted TAI. 

In abnormal cases, the MCC stored in the UE can contain elements not in the set 
{0, 1 ... 9}. In such cases the UE should transmit the stored values using full 
hexadecimal encoding. When receiving such an MCC, the network shall treat the 
TAI as deleted. 

MNC, Mobile network code (octet 3 bits 5 to 8, octet 4) 

The coding of this field is the responsibility of each administration, but BCD coding 
shall be used. The MNC shall consist of 2 or 3 digits. For PCS 1900 for NA, Federal 
regulation mandates that a 3-digit MNC shall be used. However a network operator 
may decide to use only two digits in the MNC in the TAI over the radio interface. In 
this case, bits 5 to 8 of octet 3 shall be coded as "1111 ". Mobile equipment shall 
accept a TAI coded in such a way. 

In abnormal cases, the MNC stored in the UE can have: 

- digit 1 or 2 not in the set {0, 1 ... 9}, or 

- digit 3 not in the set {0, 1 ...9, F} hex. 

In such cases the UE shall transmit the stored values using full hexadecimal 
encoding. When receiving such an MNC, the network shall treat the TAI as deleted. 

The same handling shall apply for the network, if a 3-digit MNC is sent by the UE to 
a network using only a 2-digit MNG. 

TAG, Tracking area code (octet 5 and 6) 

In the TAG field bit 8 of octet 5 is the most significant bit and bit 1 of octet 6 the 
least significant bit. 

The coding of the tracking area code is the responsibility of each administration 
except that two values are used to mark the TAG, and hence the TAI, as deleted. 
Coding using full hexadecimal representation may be used. The tracking area code 

consists of 2 octets. 

If a TAI has to be deleted then all bits of the tracking area code shall be set to one 
with the exception of the least significant bit which shall be set to zero. If a USIM is 
inserted in a mobile equipment with the tracking area code containing all zeros, 
then the mobile equipment shall recognise this TAG as part of a deleted TAI. 



9.9.3.33 Tracking area identity list 

The purpose of the Tracking area identity list information element is to transfer a list of tracking areas from the network 
to the UE. 
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The coding of the information element allows combining different types of lists. The lists of type "000" and "001" allow 
a more compact encoding, when the different TAls are sharing the PLMN identity. 

The Tracking area identity hst information element is coded as shown in figure 9.9.3.33.1, figure 9.9.3.33.2, 
figure 9.9.3.33.3, figure 9.9.3.33.4 and table 9.9.3.33.1. 

The Tracking area identity hst is a type 4 information element, with a minimum length of 8 octets and a maximum 
length of 98 octets. The list can contain a maximum of 16 different tracking area identities. 
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Figure 9.9.3.33.1 : 


Tracking area identity list information element 
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Figure 9.9.3.33.2: Partial tracking area identity list - type of list = "000" 
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Figure 9.9.3.33.3: Partial tracl(ing area identity iist - type of list = "001" 
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Figure 9.9.3.33.4: Partial tracking area identity list - type of list = "010" 
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Table 9.9.3.33.1 : Tracking area identity list information element 



Value part of the Tracking area identity list information element (octet 3 to n) 

The value part of the Tracking area identity list information element consists of one or 
several partial tracking area identity lists. The length of each partial tracking area 
identity list can be determined from the 'type of list' field and the 'number of elements' 

field in the first octet of the partial tracking area identity list. 

The UE shall store the complete list received. If more than 16 TAIs are included in this 
information element, the UE shall store the first 16 TAIs and ignore the remaining 
octets of the information element. 



Partial tracking area identity list: 

Type of list (octet 1) 

Bits 

7 6 

list of TACs belonging to one PLMN, with non-consecutive TAG values 

1 list of TACs belonging to one PLMN, with consecutive TAG values 

1 list of TAIs belonging to different PLMNs 

All other values are reserved. 

Number of elements (octet 1) 
Bits 



5 


4 


3 


2 


1 



















1 element 














1 


2 elements 











1 





3 elements 





1 


1 





1 


14 elements 





1 


1 


1 





15 elements 





1 


1 


1 


1 


16 elements 



All other values are unused and shall be interpreted as 16, if received by the UE. 
Bit 8 of octet 1 is spare and shall be coded as zero. 



For type of list = "000" and number of elements = k: 

octet 2 to 4 contain the MGG+MNG, and 
for j = 1 , k: 

octet 2j-i-3 and 2j-i-4 contain the TAG of the j-th TAI belonging to the partial list. 
For type of list = "001 " and number of elements = k: 

octet 2 to 4 contain the IVIGG+MNG, and 

octet 5 and 6 contain the TAG of the first TAI belonging to the partial list. 
The TAG values of the other k-1 TAIs are TAG+I , TAG+2, TAG+k-1 . 

For type of list = "01 0" and number of elements = k: 

for j = 1 , k. 

octet 5j-3 to 5j-1 contain the IVIGG+MNG, and 

octet 5j and 5j+1 contain the TAG of the j-th TAI belonging to the partial list. 



MGG, Mobile country code 

The MGG field is coded as in ITU-T Recommendation E.212 [30], annex A. 
MNG, Mobile network code 

The coding of this field is the responsibility of each administration but BGD coding shall 
be used. The MNG shall consist of 2 or 3 digits. If a network operator decides to use 
only two digits in the MNG, MNG digit 3 shall be coded as "1111 ". 
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TAG, Tracking area code 

In the TAG field bit 8 of the first octet is the most significant bit and bit 1 of second octet 
the least significant bit. 

The coding of the tracking area code is the responsibility of each administration. 
Coding using full hexadecimal representation may be used. The tracking area code 
consists of 2 octets. 



9.9.3.34 UE network capability 

The purpose of the UE network capability information element is to provide the network with information concerning 
aspects of the UE related to EPS or interworking with GPRS. The contents might affect the manner in which the 
network handles the operation of the UE. The UE network capability information indicates general UE characteristics 
and it shall therefore, except for fields expUcitly indicated, be independent of the frequency band of the channel it is 
sent on. 

The UE network capability information element is coded as shown in figure 9.9.3.34.1 and table 9.9.3.34.1. 

The UE network capabiUty is a type 4 information element with a minimum length of 4 octets and a maximum length of 
15 octets. 

NOTE: The requirements for the support of UMTS security algorithms in the UE are specified in 
3GPP TS 33.102 [18], and the requirements for the support of EPS security algorithms in 
3GPPTS 33.401 [19]. 
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Figure 9.9.3.34.1 : UE network capability information element 
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Table 9.9.3.34.1 : UE network capability information element 



EPS encryption algorithms supported (octet 3) 

EPS encryption algorithm EEAO supported (octet 3, bit 8) 

EPS encryption algorithm EEAO not supported 

1 EPS encryption algorithm EEAO supported 

EPS encryption algorithm 128-EEA1 supported (octet 3, bit 7) 

EPS encryption algorithm 128-EEA1 not supported 

1 EPS encryption algorithm 128-EEA1 supported 

EPS encryption algorithm 128-EEA2 supported (octet 3, bit 6) 

EPS encryption algorithm 1 28-EEA2 not supported 

1 EPS encryption algorithm 128-EEA2 supported 

EPS encryption algorithm EEA3 supported (octet 3, bit 5) 

EPS encryption algorithm EEA3 not supported 

1 EPS encryption algorithm EEA3 supported 

EPS encryption algorithm EEA4 supported (octet 3, bit 4) 

EPS encryption algorithm EEA4 not supported 

1 EPS encryption algorithm EEA4 supported 

EPS encryption algorithm EEA5 supported (octet 3, bit 3) 

EPS encryption algorithm EEA5 not supported 

1 EPS encryption algorithm EEA5 supported 

EPS encryption algorithm EEA6 supported (octet 3, bit 2) 

EPS encryption algorithm EEA6 not supported 

1 EPS encryption algorithm EEA6 supported 

EPS encryption algorithm EEA7 supported (octet 3, bit 1) 

EPS encryption algorithm EEA7 not supported 

1 EPS encryption algorithm EEA7 supported 

EPS integrity algorithms supported (octet 4) 

Bit 8 of octet 4 is spare and shall be coded as zero. 

EPS integrity algorithm 128-EIA1 supported (octet 4, bit 7) 

EPS integrity algorithm 128-EIA1 not supported 

1 EPS integrity algorithm 128-EIA1 supported 

EPS integrity algorithm 128-EIA2 supported (octet 4, bit 6) 

EPS integrity algorithm 1 28-EIA2 not supported 

1 EPS integrity algorithm 1 28-EIA2 supported 

EPS integrity algorithm EIA3 supported (octet 4, bit 5) 

EPS integrity algorithm EIA3 not supported 

1 EPS integrity algorithm EIA3 supported 

EPS integrity algorithm EIA4 supported (octet 4, bit 4) 

EPS integrity algorithm EIA4 not supported 

1 EPS integrity algorithm EIA4 supported 

EPS integrity algorithm EIA5 supported (octet 4, bit 3) 

EPS integrity algorithm EIA5 not supported 

1 EPS integrity algorithm EIA5 supported 

EPS integrity algorithm EIA6 supported (octet 4, bit 2) 

EPS integrity algorithm EIA6 not supported 

1 EPS integrity algorithm EIA6 supported 

EPS integrity algorithm EIA7 supported (octet 4, bit 1) 

EPS integrity algorithm EIA7 not supported 

1 EPS integrity algorithm EIA7 supported 
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UMTS encryption algorithms supported (octet 5) 

UMTS encryption algorithm UEAO supported (octet 5, bit 8) 

UMTS encryption algorithm UEAO not supported 

1 UMTS encryption algorithm UEAO supported 

UMTS encryption algorithm UEA1 supported (octet 5, bit 7) 

UMTS encryption algorithm UEA1 not supported 

1 UMTS encryption algorithm UEA1 supported 

UMTS encryption algorithm UEA2 supported (octet 5, bit 6) 

UMTS encryption algorithm UEA2 not supported 

1 UMTS encryption algorithm UEA2 supported 

UMTS encryption algorithm UEA3 supported (octet 5, bit 5) 

UMTS encryption algorithm UEA3 not supported 

1 UMTS encryption algorithm UEA3 supported 

UMTS encryption algorithm UEA4 supported (octet 5, bit 4) 

UMTS encryption algorithm UEA4 not supported 

1 UMTS encryption algorithm UEA4 supported 

UMTS encryption algorithm UEA5 supported (octet 5, bit 3) 

UMTS encryption algorithm UEA5 not supported 

1 UMTS encryption algorithm UEA5 supported 

UMTS encryption algorithm UEA6 supported (octet 5, bit 2) 

UMTS encryption algorithm UEA6 not supported 

1 UMTS encryption algorithm UEA6 supported 

UMTS encryption algorithm UEA7 supported (octet 5, bit 1) 

UMTS encryption algorithm UEA7 not supported 

1 UMTS encryption algorithm UEA7 supported 

UCS2 support (UCS2) (octet 6, bit 8) 

This information field indicates the likely treatment of UCS2 encoded character strings 
by the UE. 

The UE has a preference for the default alphabet (defined in 
3GPP TS 23.038 [3]) over UCS2 (see ISO/IEC 10646 [29]). 

1 The UE has no preference between the use of the default alphabet and 

the use of UCS2. 

UMTS integrity algorithms supported (octet 6) 

UMTS integrity algorithm UIA1 supported (octet 6, bit 7) 

UMTS integrity algorithm UIA1 not supported 

1 UMTS integrity algorithm UIA1 supported 

UMTS integrity algorithm UIA2 supported (octet 6, bit 6) 

UMTS integrity algorithm UIA2 not supported 

1 UMTS integrity algorithm UIA2 supported 

UMTS integrity algorithm UIA3 supported (octet 6, bit 5) 

UMTS integrity algorithm UIA3 not supported 

1 UMTS integrity algorithm UIA3 supported 

UMTS integrity algorithm UIA4 supported (octet 6, bit 4) 

UMTS integrity algorithm UIA4 not supported 

1 UMTS integrity algorithm UIA4 supported 

UMTS integrity algorithm UIA5 supported (octet 6, bit 3) 

UMTS integrity algorithm UIA5 not supported 

1 UMTS integrity algorithm UIA5 supported 

UMTS integrity algorithm UIA6 supported (octet 6, bit 2) 
UMTS integrity algorithm UIA6 not supported 

J UMTS integrity algorithm UIA6 supported 
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UMTS integrity algoritlim UIA7 supported (octet 6, bit 1) 

UIVITS integrity algoritiim UIA7 not supported 

1 UIVITS integrity algoritlim UIA7 supported 

Bits 8 to 3 and bit 1 of octet 7 are spare and shall be coded as zero. 
IxSRVCC capability (octet 7, bit 2) 

SRVCC from E-UTRAN to cdma2000® 1 x CS not supported 

1 SRVCC from E-UTRAN to cdma2000® 1 xCS supported 
(see 3GPPTS 23.21 6 [8]) 

All other bits In octet 8 to 15 are spare and shall be coded as zero, if the respective 
octet is included in the information element. 



9.9.3.35 UE radio capability information update needed 

The purpose of the UE radio capability information update needed information element is to indicate whether the MME 
shall delete the stored UE radio capabihty information, if any. 

The UE radio capabihty information update needed information element is coded as shown in figure 9.9. 3.35. land 
table 9.9.3.35.1. 

The UE radio capabihty information update needed is a type 1 information element. 
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Figure 9.9.3.35.1: UE radio capabiiity information update needed information element 



Table 9.9.3.35.1 : UE radio capability information update needed information element 



UE radio capability information update needed flag (URC upd) (octet 1) 

Bit 

1 

UE radio capability information update not needed 

1 UE radio capability information update needed 



9.9.3.36 UE security capability 

The UE security capability information element is used by the network to indicate which security algorithms are 
supported by the UE in SI mode, lu mode and Gb mode. Security algorithms supported in SI mode are supported both 
for NAS and for AS security. If the UE supports SlOl mode, then these security algorithms are also supported for NAS 

security in S 101 mode. 

The UE security capability information element is coded as shown in figure 9.9.3.36.1 and table 9.9.3.36.1. 

The UE security capability is a type 4 information element with a minimum length of 4 octets and a maximum length of 

7 octets. 

Octets 5, 6, and 7 are optional. If octet 5 is included, then also octet 6 shall be included and octet 7 may be included. 

If a UE did not indicate support of any security algorithm for Gb mode, octet 7 shall not be included. If the UE did not 
indicate support of any security algorithm for lu mode and Gb mode, octets 5, 6, and 7 shall not be included. 
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Figure 9.9.3.36.1 : UE security capability information element 
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Table 9.9.3.36.1 : UE security capability information element 



EPS encryption algorithms supported (octet 3) 

EPS encryption algorithm EEAO supported (octet 3, bit 8) 

EPS encryption algorithm EEAO not supported 

1 EPS encryption algorithm EEAO supported 

EPS encryption algorithm 128-EEA1 supported (octet 3, bit 7) 

EPS encryption algorithm 128-EEA1 not supported 

1 EPS encryption algorithm 128-EEA1 supported 

EPS encryption algorithm 128-EEA2 supported (octet 3, bit 6) 

EPS encryption algorithm 1 28-EEA2 not supported 

1 EPS encryption algorithm 128-EEA2 supported 

EPS encryption algorithm EEA3 supported (octet 3, bit 5) 

EPS encryption algorithm EEA3 not supported 

1 EPS encryption algorithm EEA3 supported 

EPS encryption algorithm EEA4 supported (octet 3, bit 4) 

EPS encryption algorithm EEA4 not supported 

1 EPS encryption algorithm EEA4 supported 

EPS encryption algorithm EEA5 supported (octet 3, bit 3) 

EPS encryption algorithm EEA5 not supported 

1 EPS encryption algorithm EEA5 supported 

EPS encryption algorithm EEA6 supported (octet 3, bit 2) 

EPS encryption algorithm EEA6 not supported 

1 EPS encryption algorithm EEA6 supported 

EPS encryption algorithm EEA7 supported (octet 3, bit 1) 

EPS encryption algorithm EEA7 not supported 

1 EPS encryption algorithm EEA7 supported 

EPS integrity algorithms supported (octet 4) 

Bit 8 of octet 4 is spare and shall be coded as zero. 

EPS integrity algorithm 128-EIA1 supported (octet 4, bit 7) 

EPS integrity algorithm 128-EIA1 not supported 

1 EPS integrity algorithm 128-EIA1 supported 

EPS integrity algorithm 128-EIA2 supported (octet 4, bit 6) 

EPS integrity algorithm 1 28-EIA2 not supported 

1 EPS integrity algorithm 1 28-EIA2 supported 

EPS integrity algorithm EIA3 supported (octet 4, bit 5) 

EPS integrity algorithm EIA3 not supported 

1 EPS integrity algorithm EIA3 supported 

EPS integrity algorithm EIA4 supported (octet 4, bit 4) 

EPS integrity algorithm EIA4 not supported 

1 EPS integrity algorithm EIA4 supported 

EPS integrity algorithm EIA5 supported (octet 4, bit 3) 

EPS integrity algorithm EIA5 not supported 

1 EPS integrity algorithm EIA5 supported 

EPS integrity algorithm EIA6 supported (octet 4, bit 2) 

EPS integrity algorithm EIA6 not supported 

1 EPS integrity algorithm EIA6 supported 

EPS integrity algorithm EIA7 supported (octet 4, bit 1) 

EPS integrity algorithm EIA7 not supported 

1 EPS integrity algorithm EIA7 supported 
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UMTS encryption algorithms supported (octet 5) 

UMTS encryption algorithm UEAO supported (octet 5, bit 8) 

UMTS encryption algorithm UEAO not supported 

1 UMTS encryption algorithm UEAO supported 

UMTS encryption algorithm UEA1 supported (octet 5, bit 7) 

UMTS encryption algorithm UEA1 not supported 

1 UMTS encryption algorithm UEA1 supported 

UMTS encryption algorithm UEA2 supported (octet 5, bit 6) 

UMTS encryption algorithm UEA2 not supported 

1 UMTS encryption algorithm UEA2 supported 

UMTS encryption algorithm UEA3 supported (octet 5, bit 5) 

UMTS encryption algorithm UEA3 not supported 

1 UMTS encryption algorithm UEA3 supported 

UMTS encryption algorithm UEA4 supported (octet 5, bit 4) 

UMTS encryption algorithm UEA4 not supported 

1 UMTS encryption algorithm UEA4 supported 

UMTS encryption algorithm UEA5 supported (octet 5, bit 3) 

UMTS encryption algorithm UEA5 not supported 

1 UMTS encryption algorithm UEA5 supported 

UMTS encryption algorithm UEA6 supported (octet 5, bit 2) 

UMTS encryption algorithm UEA6 not supported 

1 UMTS encryption algorithm UEA6 supported 

UMTS encryption algorithm UEA7 supported (octet 5, bit 1) 

UMTS encryption algorithm UEA7 not supported 

1 UMTS encryption algorithm UEA7 supported 

UMTS integrity algorithms supported (octet 6) 

Bit 8 of octet 6 is spare and shall be coded as zero. 

UMTS integrity algorithm UIA1 supported (octet 6, bit 7) 

UMTS integrity algorithm UIA1 not supported 

1 UMTS integrity algorithm UIA1 supported 

UMTS integrity algorithm UIA2 supported (octet 6, bit 6) 

UMTS integrity algorithm UIA2 not supported 

1 UMTS integrity algorithm UIA2 supported 

UMTS integrity algorithm UIA3 supported (octet 6, bit 5) 

UMTS integrity algorithm UIA3 not supported 

1 UMTS integrity algorithm UIA3 supported 

UMTS integrity algorithm UIA4 supported (octet 6, bit 4) 

UMTS integrity algorithm UIA4 not supported 

1 UMTS integrity algorithm UIA4 supported 

UMTS integrity algorithm UIA5 supported (octet 6, bit 3) 

UMTS integrity algorithm UIA5 not supported 

1 UMTS integrity algorithm UIA5 supported 

UMTS integrity algorithm UIA6 supported (octet 6, bit 2) 

UMTS integrity algorithm UIA6 not supported 

1 UMTS integrity algorithm UIA6 supported 

UMTS integrity algorithm UIA7 supported (octet 6, bit 1) 

UMTS integrity algorithm UIA7 not supported 

1 UMTS integrity algorithm UIA7 supported 

GPRS encryption algorithms supported (octet 7) 
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Bit 8 of octet 7 is spare and shall be coded as zero. 

GPRS encryption algorithm GEA1 supported (octet 7, bit 7) 

GPRS encryption algorithm GEA1 not supported 

1 GPRS encryption algorithm GEA1 supported 

GPRS encryption algorithm GEA2 supported (octet 7, bit 6) 

GPRS encryption algoritlim GEA2 not supported 

1 GPRS encryption algorithm GEA2 supported 

GPRS encryption algorithm GEA3 supported (octet 7, bit 5) 

GPRS encryption algorithm GEA3 not supported 

1 GPRS encryption algorithm GEA3 supported 

GPRS encryption algorithm GEA4 supported (octet 7, bit 4) 

GPRS encryption algorithm GEA4 not supported 

1 GPRS encryption algorithm GEA4 supported 

GPRS encryption algorithm GEA5 supported (octet 7, bit 3) 

GPRS encryption algorithm GEA5 not supported 

1 GPRS encryption algorithm GEA5 supported 

GPRS encryption algorithm GEA6 supported (octet 7, bit 2) 

GPRS encryption algorithm GEA6 not supported 

1 GPRS encryption algorithm GEA6 supported 

GPRS encryption algorithm GEA7 supported (octet 7, bit 1) 

GPRS encryption algorithm GEA7 not supported 

1 GPRS encryption algorithm GEA7 supported 



9.9.3.37 Emergency Number List 

See subclause 10.5.3.13 in 3GPP TS 24.008 [13]. 

9.9.3.38 CLI 

The purpose of the CLI information element is to convey information about the calling hne for a terminated call to a CS 
fallback capable UE. 

The CLI information element is coded as shown in figure 9.9.3.38.1 and table 9.9.3.38.1. 

The CLI is a type 4 information element with a minimum length of 3 octets and a maximum length of 14 octets. 



8 7 6 5 4 3 2 1 

CLI lEI 

Length of CLI 

CLI (value part) 



Figure 9.9.3.38.1 : CLI information element 
Table 9.9.3.38.1: CLI information element 



CLI (value part) 

The coding of the CLI value part is the same as for octets 3 to 14 of the Calling party 
BCD number information element defined in subclause 10.5.4.9 of 
3GPPTS 24.008 [13]. 



octet 1 
octet 2 
octet 3 
to 

octet 1 4 
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9.9.3.39 



SS Code 



The purpose of the SS code information element is to convey information related to a network initiated supplementary 
service request to a CS fallback capable UE. 

The SS Code information element is coded as shown in figure 9.9.3.39.1 and table 9.9.3.39.1. 
The SS Code is a type 3 information element with 2 octets length. 



SS Code lEI 



SS Code value 



octet 1 
octet 2 



Figure 9.9.3.39.1 : SS Code information element 
Table 9.9.3.39.1 : SS Code information element 



SS Code value 

The coding of the SS Code value is given in subclause 17.7.5 of 
3GPPTS 29.002 [15B]. 



9.9.3.40 LCS indicator 

The purpose of the LCS indicator information element is to indicate that the origin of the message is due to a LCS 
request and the type of this request to a CS fallback capable UE. 

The LCS indicator information element is coded as shown in figure 9.9.3.40.1 and table 9.9.3.40.1. 
The LCS indicator is a type 3 information element with 2 octets length. 



LCS indicator IE! 



LCS indicator value 



octet 1 
octet 2 



Figure 9.9.3.40.1 : LCS indicator information element 
Table 9.9.3.40.1: LCS indicator information element 



LCS indicator value 


Bits 




8765432 1 




00000000 


Normal, unspecified in this version of the protocol. 


0000000 1 


MT-LR 


10 




to 


Normal, unspecified in this version of the protocol 


11111111 





9.9.3.41 LCS client identity 

The piupose of the LCS client identity information element is to convey information related to the client of a LCS 
request for a CS fallback capable UE. 

The LCS cUent identity information element is coded as shown in figure 9.9.3.41.1 and table 9.9.3.41.1. 
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The LCI client identity is a type 4 information element with a minimum length of 3 octets and a maximum length of 
257 octets. 



LCS client identity lEI 



Length of LCS client identity 



LCS client identity (value part) 



octet 1 
octet 2 
octet 3 
to 

octet 257 



Figure 9.9.3.41.1 : LCS client identity information element 
Table 9.9.3.41.1 : LCS client Identity Information element 



LCS client identity (value part) 

The coding of the value part of the LCS cUent identity is given in subclause 17.7.13 of 
3GPPTS 29.002 [15B]. 



9.9.4 EPS Session Management (ESM) information elements 

9.9.4.1 Access point name 

See subclause 10.5.6.1 in 3GPP TS 24.008 [13]. 

9.9.4.2 APN aggregate maximum bit rate 

The purpose of the APN aggregate maximum bit rate information element is to indicate the initial subscribed APN- 
AMBR when the UE establishes a PDN connection or to indicate the new APN-AMBR if it is changed by the network. 

The APN aggregate maximum bit rate information element is coded as shown in figure 9.9.4.2.1 and table 9.9.4.2.1. 

The APN aggregate maximum bit rate is a type 4 information element with a minimum length of 4 octets and a 
maximum length of 8 octets. 



APN aggregate maximum bit rate lEI 



octet 1 
octet 2 
octet 3 
octet 4 
octet 5 
octet 6 
octet 7 
octet 8 



Length of APN aggregate maximum bit rate contents 



APN-AMBR for downlink 



APN-AMBR for uplink 



APN-AMBR for downlink (extended) 



APN-AMBR for uplink (extended) 



APN-AMBR for downlink (extended-2) 



APN-AMBR for uplink (extended-2) 



Figure 9.9.4.2.1 : APN aggregate maximum bit rate information element 
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Table 9.9.4.2.1 : APN aggregate maximum bit rate information element 

APN-AMBR for downlink, octet 3 
Bits 

8765432 1 

00000000 Reserved 

1 Tine APN-AMBR is binary coded in 8 bits, using a granularity of 1 l<bps 

to giving a range of values from 1 kbps to 63 kbps in 1 kbps increments. 
111111 

1 The APN-AMBR is 64 kbps + ((the binary coded value in 8 bits -01 000000) * 8 kbps) 

to giving a range of values from 64 kbps to 568 kbps in 8 kbps increments. 

1111111 

1 The APN-AMBR is 576 kbps + ((the binary coded value in 8 bits -1 0000000) * 64 kbps) 

to giving a range of values from 576 kbps to 8640 kbps in 64 kbps increments. 
11111110 

11111111 0kbps 

If the network wants to indicate an APN-AMBR for downlink higher than 8640 kbps, it shall set octet 3 to '1 1 1 1 1 1 1 0', i.e. 
8640 kbps, and shall encode the value for the APN-AMBR in octet 5. 

APN-AMBR for uplink, octet 4 

Coding is identical to that of APN-AMBR for downlink. 



APN-AMBR for downlink (extended), octet 5 
Bits 

8765432 1 

00000000 Use the value indicated by the APN-AMBR for downlink in octet 3. 

For all other values: Ignore the value indicated by the APN-AMBR for downlink in octet 3 
and use the following value: 



00 





0000 


1 


The APN-AMBR is 8600 kbps + ((the binary coded value in 8 bits) * 100 kbps), 






to 




giving a range of values from 8700 kbps to 16000 kbps in 100 kbps increments. 


1 





10 1 







1 





10 1 


1 


The APN-AMBR is 16 Mbps + ((the binary coded value in 8 bits - 01001010) * 1 Mbps), 






to 




giving a range of values from 17 Mbps to 128 Mbps in 1 Mbps increments. 


1 


1 


110 1 







1 


1 


110 1 


1 


The APN-AMBR is 1 28 Mbps + ((the binary coded value in 8 bits - 1 01 1 1 01 0) * 2 Mbps), 






to 




giving a range of values from 130 Mbps to 256 Mbps in 2 Mbps increments. 


1 1 


1 


110 1 








All other values shall be interpreted as '1 1 1 1 1 1 0'. 



APN-AMBR for uplink (extended), octet 6 

This field is an extension of the APN-AMBR for uplink in octet 4. The coding is identical to that of the APN-AMBR for 
downlink (extended). 



APN-AMBR for downlink (extended-2), octet 7 
Bits 

8765432 1 

00000000 Use the value indicated by the APN-AMBR for downlink and APN-AMBR for downlink (extended) in 
octets 3 and 5. 

1 The APN-AMBR is (the binary coded value in 8 bits) * 256 Mbps + (the value indicated by 
to the APN-AMBR for downlink and APN-AMBR for downlink (extended) in octets 3 and 5), 
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11111110 giving a range of 256 IVIbps to 65280 Mbps. 

11111111 This value shall be interpreted as '0 0' in this version of the specification. 
APN-AMBR for uplink (extended-2), octet 8 

This field is an extension of the APN-AMBR for uplink and APN-AMBR for uplink (extended) in octets 4 and 6. The 
coding is identical to that of the APN-AMBR for downlink (extended-2). 



9.9.4.3 EPS quality of service 

The piupose of the EPS quahty of service information element is to specify the QoS parameters for an EPS bearer 
context. 

The EPS quality of service information element is coded as shown in figure 9.9.4.3.1 and table 9.9.4.3.1. 

The EPS quality of service is a type 4 information element with a minimum length of 3 octets and a maximum length of 
1 1 octets. Octets 4-1 1 are optional. If octet 4 is included, then octets 5-7 shall also be included, and octets 8-11 may be 
included. If octet 8 is included, then octets 4-11 shall also be included. The length of the EPS QoS IE can be either 3 
octets, 7 octets or 11 octets. 

Refer to 3GPP TS 23.203 [7] for a detailed description of the QoS Class Identifier (QCI). 



8 7 6 5 4 3 2 1 



EPS quality of service lEI 


octet 1 


Length of EPS quality of service contents 


octet 2 


QCI 


octet 3 


Maximum bit rate for uplink 


octet 4* 


Maximum bit rate for downlink 


octet 5* 


Guaranteed bit rate for uplink 


octet 6* 


Guaranteed bit rate for downlink 


octet 7* 


Maximum bit rate for uplink (extended) 


octet 8* 


Maximum bit rate for downlink (extended) 


octet 9* 


Guaranteed bit rate for uplink (extended) 


octet 1 0* 


Guaranteed bit rate for downlink (extended) 


octet 1 1 * 



Figure 9.9.4.3.1 : EPS quality of service information element 
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Table 9.9.4.3.1 : EPS quality of service information element 

Quality of Service Class Identifier (QCI), octet 3 (see 3GPP TS 23.203 [7]) 
Bits 

8765432 1 

In UE to network direction: 

00000000 Network selects the QCI 

In network to UE direction: 
00000000 Reserved 

In UE to network direction and In network to UE direction: 

1 QCI 1 

00000010 QCI 2 

1 1 QCI 3 

00000100 QCI 4 

1 1 QCI 5 

1 1 QCI 6 

1 1 1 QCI 7 

00001000 QCI 8 

1 1 QCI 9 

11111111 Reserved 

The network shall map all other values not explicitly defined onto one of the values defined in this version of the 
protocol. The network shall return a negotiated value which is explicitly defined in this version of this protocol. 

The UE shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. 



For all non-GBR QCIs, the maximum and guaranteed bit rates shall be ignored. 


Maximum bit rate for uplink, octet 4 (see 3GPP TS 23.107 [5]) 


Bits 




8765432 1 




In UE to network 


direction: 


00000000 


Subscribed maximum bit rate for uplink 


In network to UE 


direction: 


00000000 


Reserved 


In UE to network 


direction and in network to UE direction: 


00000001 


The maximum bit rate is binary coded in 8 bits, using a granularity of 1 kbps 


to 


giving a range of values from 1 kbps to 63 kbps in 1 kbps increments. 


111111 




1000000 


The maximum bit rate is 64 kbps + ((the binary coded value in 8 bits - 01000000) * 8 kbps) 


to 


giving a range of values from 64 kbps to 568 kbps in 8 kbps increments. 


1111111 




10000000 


The maximum bit rate is 576 kbps + ((the binary coded value in 8 bits - 10000000) * 64 kbps) 


to 


giving a range of values from 576 kbps to 8640 kbps in 64 kbps increments. 


11111110 




11111111 


0kbps 



If the sending entity wants to indicate a maximum bit rate for uplink higher than 8640 kbps, it shall set octet 4 to 
'11111110', i.e. 8640 kbps, and shall encode the value for the maximum bit rate in octet 8. 



Maximum bit rate for downlink, octet 5 (see 3GPP TS 23.107 [5]) 
Coding is identical to that of maximum bit rate for uplink. 

If the sending entity wants to indicate a maximum bit rate for downlink higher than 8640 kbps, it shall set octet 5 to 
'1 1 1 1 1 1 1 0', i.e. 8640 kbps, and shall encode the value for the maximum bit rate in octet 9. 

In this version of the protocol, for messages specified in the present document, the sending entity shall not request 
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kbps for both the maximum bit rate for downlinl< and the maximum bit rate for uplink at the same time. Any entity 
receiving a request for kbps in both the maximum bit rate for downlink and the maximum bit rate for uplink shall 
consider that as a syntactical error (see clause 8 of 3GPP TS 24.008 [13]). 



Guaranteed bit rate for uplink, octet 6 (see 3GPP TS 23.107 [5]) 
Coding is identical to that of maximum bit rate for uplink. 

If the sending entity wants to indicate a guaranteed bit rate for uplink higher than 8640 kbps, it shall set octet 6 to 
'11111110', i.e. 8640 kbps, and shall encode the value for the guaranteed bit rate in octet 10. 



Guaranteed bit rate for downlink, octet 7 (see 3GPP TS 23.107 [5]) 

Coding is identical to that of maximum bit rate for uplink. 

If the sending entity wants to indicate a guaranteed bit rate for downlink higher than 8640 kbps, it shall set octet 7 to 
'11111110', i.e. 8640 kbps, and shall encode the value for the guaranteed bit rate in octet 1 1 . 



Maximum bit rate for uplink (extended), octet 8 
Bits 

8765432 1 

In UE to network direction and in network to UE direction: 

00000000 Use the value indicated by the maximum bit rate for uplink in octet 4. 

For all other values: ignore the value indicated by the maximum bit rate for uplink in octet 4 

and use the following value: 
1 The maximum bit rate is 8600 kbps + ((the binary coded value in 8 bits) * 1 00 kbps), 

to giving a range of values from 8700 kbps to 1 6000 kbps in 1 00 kbps increments. 

1001010 

10 10 11 The maximum bit rate is 16 Mbps + ((the binary coded value in 8 bits - 01001010) * 1 Mbps), 

to giving a range of values from 1 7 Mbps to 1 28 Mbps in 1 Mbps increments. 

10 1110 10 

10 1110 11 The maximum bit rate is 128 Mbps + ((the binary coded value in 8 bits - 101 1 1010) * 2 Mbps), 

to giving a range of values from 1 30 Mbps to 256 Mbps in 2 Mbps increments. 

111110 10 

The network shall map all other values not explicitly defined onto one of the values defined in this version of the 
protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol. 



Maximum bit rate for downlink (extended), octet 9 

This field is an extension of the maximum bit rate for downlink in octet 5. The coding is identical to that of the maximum 
bit rate for uplink (extended). 

The network shall map all other values not explicitly defined onto one of the values defined in this version of the 
protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol. 



Guaranteed bit rate for uplink (extended), octet 10 
Bits 

8765432 1 

In UE to network direction and in network to UE direction: 

00000000 Use the value indicated by the guaranteed bit rate for uplink in octet 6. 

For all other values: ignore the value indicated by the guaranteed bit rate for uplink in octet 6 

and use the following value: 
1 The guaranteed bit rate is 8600 kbps + ((the binary coded value in 8 bits) * 1 00 kbps), 

to giving a range of values from 8700 kbps to 1 6000 kbps in 1 00 kbps increments. 

1001010 

10 10 11 The guaranteed bit rate is 16 Mbps + ((the binary coded value in 8 bits - 01001010) * 1 Mbps), 
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to giving a range of values from 17 Mbps to 128 Mbps in 1 Mbps increments. 

10 1110 10 

10 1110 11 The guaranteed bit rate is 1 28 IVibps + ((the binary coded value in 8 bits - 1 01 1 1 01 0) * 2 Mbps), 

to giving a range of values from 1 30 Mbps to 256 Mbps in 2 Mbps increments. 

111110 10 

The network shall map all other values not explicitly defined onto one of the values defined in this version of the 
protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol. 



Guaranteed bit rate for downlink (extended), octet 1 1 

This field is an extension of the guaranteed bit rate for downlink in octet 7. The coding is identical to that of guaranteed 
bit rate for uplink (extended). 

The network shall map all other values not explicitly defined onto one of the values defined in this version of the 
protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol. 



9.9.4.4 ESM cause 

The piupose of the ESM cause information element is to indicate the reason why a session management request is 
rejected. 

The ESM cause information element is coded as shown in figure 9.9.4.4.1 and table 9.9.4.4.1. 

The ESM cause is a type 3 information element with 2 octets length. 



ESM cause lEI 



octet 1 
octet 2 



Cause value 



Figure 9.9.4.4.1 : ESM cause information element 
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Table 9.9.4.4.1 : ESM cause information element 



Cause value (octet 2) 

Bits 



8 


7 


6 


5 


4 


3 


2 


1 



























Operator Determined Barring 











1 







1 





Insufficient resources 











1 







1 


1 


Unl<nown or missing APN 











1 




1 








Unl<nown PDN type 











1 




1 





1 


User authentication failed 











1 




1 


1 





Activation rejected by Serving GW or PDN GW 











1 




1 


1 


1 


Activation rejected, unspecified 








1 

















Service option not supported 








1 














1 


Requested service option not subscribed 








1 











1 





Service option temporarily out of order 








1 











1 


1 


PTI already in use 








1 








1 








Regular deactivation 








1 








1 





1 


EPS QoS not accepted 








1 








1 


1 





Network failure 








1 





1 








1 


Semantic error in the TFT operation 








1 





1 





1 





Syntactical error in the TFT operation 








1 





1 





1 


1 


Invalid EPS bearer identity 








1 





1 


1 








Semantic errors in packet filter(s) 








1 





1 


1 





1 


Syntactical errors in packet filter(s) 








1 





1 


1 


1 





EPS bearer context without TFT already activated 








1 





1 


1 


1 


1 


PTI mismatch 








1 













1 


Last PDN disconnection not allowed 








1 


1 








1 





PDN type IPv4 only allowed 








1 










1 


1 


PDN type IPv6 only allowed 








1 


1 





1 








Single address bearers only allowed 








1 







1 





1 


ESM information not received 








1 







1 


1 





PDN connection does not exist 








1 







1 


1 


1 


Multiple PDN connections for a given APN not 
allowed 








1 




1 











Collision with network initiated request 


u 


1 


u 




u 


n 

u 


n 

u 


H 

1 


Invalid PTI value 





1 







1 


1 


1 


1 


Semantically incorrect message 





1 


1 

















Invalid mandatory information 





1 


1 














1 


Message type non-existent or not implemented 





1 


1 











1 





Message type not compatible with the protocol 
state 





1 


1 











1 


1 


Information element non-existent or not 
implemented 





1 


1 








1 








Conditional IE error 





1 


1 








1 





1 


Message not compatible with the protocol state 





1 


1 





1 


1 


1 


1 


Protocol error, unspecified 





1 


1 


1 














APN restriction value incompatible with active 



EPS bearer context 



Any other value received by the UE shall be treated as 0010 0010, "Service option 
temporarily out of order". Any other value received by the network shall be treated as 
01 10 1 1 1 1 , "Protocol error, unspecified". 

NOTE: The listed cause values are defined in annex B. 



9.9.4.5 ESM information transfer flag 

The purpose of the ESM information transfer flag information element is to indicate whether ESM information, i.e. 
protocol configuration options or APN or both, is to be transferred security protected. 

The ESM information transfer flag information element is coded as shown in figure 9.9.4.5.1 and table 9.9.4.5.1. 
The ESM information transfer flag is a type 1 information element. 
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ESM information transfer flag lEI 











BIT 


octet 1 






spare 




value 





Figure 9.9.4.5.1: ESIVI information transfer fiag information element 
Table 9.9.4.5.1 : ESM information transfer flag information element 



EIT (ESM information transfer) 



Bit 
1 

1 



security protected ESIVI information transfer not required 
security protected ESM information transfer required 



9.9.4.6 



Linked EPS bearer identity 



The purpose of the Linked EPS bearer identity IE is to identify the default bearer that is associated with a dedicated EPS 
bearer or to identify the dedicated EPS bearer to which a specific packet filter is associated. 

The Linked EPS bearer identity information element is coded as shown in figure 9.9.4.6.1 and table 9.9.4.6.1. 

The Linked EPS bearer identity is a type 1 information element. 



8 



1 



Linked EPS bearer identity lEI 



Linked EPS bearer identity value 



octet 1 



Figure 9.9.4.6.1: Linked EPS bearer identity information element 
Table 9.9.4.6.1 : Linked EPS bearer identity information element 



Linked EPS bearer identity (bits 1-4) 



4 


3 


2 


1 
































to 




Reserved 









1 



















1 





1 


EPS 


bearer 


identity value 


5 





1 


1 





EPS 


bearer 


identity value 


6 





1 


1 


1 


EPS 


bearer 


identity value 


7 


1 











EPS 


bearer 


identity value 


8 


1 








1 


EPS 


bearer 


identity value 


9 


1 





1 





EPS 


bearer 


identity value 


10 


1 





1 


1 


EPS 


bearer 


identity value 


11 


1 


1 








EPS 


bearer 


identity value 


12 


1 


1 





1 


EPS 


bearer 


identity value 


13 


1 


1 


1 





EPS 


bearer 


identity value 


14 


1 


1 


1 


1 


EPS 


bearer 


identity value 


15 



9.9.4.7 LLC service access point identifier 

See subclause 10.5.6.9 in 3GPP TS 24.008 [13]. 
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9.9.4.8 Packet flow identifier 

See subclause 10.5.6.11 in 3GPP TS 24.008 [13]. 

9.9.4.9 PDN address 

The purpose of the PDN address information element is to assign an IPv4 address to the UE associated with a packet 
data network and to provide the UE with an interface identifier to be used to build the IPv6 link local address. 

The PDN address information element is coded as shown in figure 9.9.4.9.1 and table 9.9.4.9.1. 

The PDN address is a type 4 information element with minimum length of 7 octets and a maximum length of 15 octets. 



PDN address lEI 



Length of PDN address contents 





spare 



PDN type value 



PDN address information 



octet 1 
octet 2 
octet 3 



octet 4 
octet 1 5 



Figure 9.9.4.9.1: PDN address information element 
Table 9.9.4.9.1 : PDN address information element 



PDN type value (octet 3) 
Bits 

3 2 1 

1 IPv4 
1 IPv6 
1 1 IPv4v6 

All other values are reserved. 

Bit 4 to 8 of octet 3 are spare and shall be coded as zero. 
PDN address information (octet 4 to 1 5) 

If PDN type value indicates IPv4, the PDN address information in octet 4 to octet 7 
contains an IPv4 address. Bit 8 of octet 4 represents the most significant bit of the IPv4 
address and bit 1 of octet 7 the least significant bit. 

If PDN type value indicates IPv6, the PDN address information in octet 4 to octet 1 1 
contains an IPv6 interface identifier. Bit 8 of octet 4 represents the most significant bit 
of the IPv6 interface identifier and bit 1 of octet 1 1 the least significant bit. 



If PDN type value indicates IPv4v6, the PDN address information in octet 4 to octet 15 
contains an IPv6 interface identifier and an IPv4 address. Bit 8 of octet 4 represents 
the most significant bit of the IPv6 interface identifier and bit 1 of octet 1 1 the least 
significant bit. Bit 8 of octet 12 represents the most significant bit of the iPv4 address 
and bit 1 of octet 15 the least significant bit. 

If PDN type value indicates IPv4 or IPv4v6 and DHCPv4 is to be used to allocate the 
IPv4 address, the IPv4 address shall be coded as 0.0.0.0. 



9.9.4.10 PDN type 

The purpose of the PDN type information element is to indicate the IP version capability of the IP stack associated with 
the UE. 
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The PDN type information element is coded as shown in figure 9.9.4.10.1 and table 9.9.4.10.1. 
The PDN type is a type 1 information element. 



8 7 6 5 4 3 2 1 



PDN type lEI 





PDN type value 


octet 1 




Spare 







Figure 9.9.4.10.1 : PDN type information element 



Table 9.9.4.10.1: PDN type information element 

RON type value (octet 1) 
Bits 

3 2 1 

1 IPv4 
1 IPv6 

1 1 IPv4v6 

1 unused; shall be interpreted as "IPv6" if received by the network 
All other values are reserved. 

Bit 4 of octet 1 is spare and shall be coded as zero. 



9.9.4.1 1 Protocol configuration options 

See subclause 10.5.6.3 in 3GPP TS 24.008 [13]. 

9.9.4.12 Quality of service 

See subclause 10.5.6.5 in 3GPP TS 24.008 [13]. 

9.9.4.13 Radio priority 

See subclause 10.5.7.2 in 3GPP TS 24.008 [13]. 

9.9.4.14 Request type 

See subclause 10.5.6.17 in 3GPP TS 24.008 [13j. 

9.9.4.15 Traffic flow aggregate description 

The purpose of the Traffic flow aggregate description information element is to specify the aggregate of one of more 
packet filters and their related parameters and operations. The traffic flow aggregate description may contain the 
aggregate of packet filters for the downlink direction, the uplink direction or packet filters that apply for both directions. 
The packet filters determine the traffic mapping to EPS bearer contexts. The downlink packet filters shall be applied by 
the network, and the uplink packet filters shall be applied by the UE. A packet filter that apphes for both directions shall 
be apphed by the network as a downlink packet filter and by the UE as an uphnk packet filter. 

When the traffic flow aggregate description is used in the UE requested bearer resource allocation procedure or the UE 
requested bearer resource modification procedure, it is associated to a particular procedure identified by a procedure 
transaction identity (PTI). Therefore, the UE shall release the traffic flow aggregate description when the UE requested 
bearer resource allocation procedure or the UE requested bearer resource modification procedure is completed. The UE 
shall not include the packet filters of a particular traffic flow aggregate description in any other traffic flow aggregate 
description when multiple UE requested bearer resource allocation procedures and/or UE requested bearer resource 
modification procedures are ongoing in parallel. 
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The Traffic flow aggregate description information element is encoded using the same format as the Traffic flow 
template (TFT) information element (see subclause 10.5.6.12 in 3GPP TS 24.008 [13]). When sending this IE in the 
BEARER RESOURCE ALLOCATION REQUEST message, the UE shall set the packet filter identifier values to 0. 
When sending this IE in the BEARER RESOURCE MODIFICATION REQUEST message, the UE shall set the packet 
filter identifier values from those of already assigned packet filter identifiers of the existing EPS bearer, so that they are 
unique across all packet filters for the EPS bearer context indicated by the EPS bearer identity IE. 

9.9.4.1 6 Traffic flow template 

See subclause 10.5.6.12 in 3GPP TS 24.008 [13]. 

9.9.4.17 Transaction identifier 

The piupose of the Transaction identifier information element is to represent the corresponding PDP context in A/Gb 
mode or lu mode which is mapped from the EPS bearer context. 

The Transaction identifier information element is coded as the Linked TI information element in 3GPP TS 24.008 [13], 
subclause 10.5.6.7. 



10 



List of system parameters 



10.1 



General 



The description of timers in the following tables should be considered a brief summary. 
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10.2 Timers of EPS mobility management 



Table 10.2.1 : EPS mobility management timers - UE side 



TIMER 
NUM. 


TIMER 
VALUE 


STATE 


CAUSE OF START 


NORMAL STOP 


ON 
EXPIRY 


T3402 


Default 12 
min. 
NOTE 1 


EMM- 
DEREGISTERED 
EMM- 
REGISTERED 


At attach failure and the attempt 
counter is equal to 5. 
At tracking area updating failure 
and the attempt counter is equal 
to 5. 


ATTACH REQUEST 
sent 

TRACKING AREA 
UPDATE 
REQUEST sent 


Initiation of the 
attach procedure or 
TAU procedure 


T3410 


15s 


EMM- 
REGISTERED- 
INITIATED 


ATTACH REQUEST sent 


ATTACH ACCEPT 
received 

ATTACH REJECT 
received 


Start T341 1 or 
T3402 as described 

in 

subclause 5.5.1 .2.6 


T3411 


10s 


EMM- 
DEREGISTERED. 
ATTEMPTING- 
TO-ATTACH 

EMM- 
REGISTERED. 
ATTEMPTING- 
TO-UPDATE 


At attach failure due to lower 
layer failure, T341 timeout or 
attach rejected with other EMM 
cause values than those treated 
in subclause 5.5.1.2.5. 

At tracking area updating failure 
due to lower layer failure, T3430 
timeout or TAU rejected with 
other EMM cause values than 
those treated in 
subclause 5.5.3.2.5. 


ATTACH REQUEST 
sent 

TRACKING AREA 
UPDATE 
REQUEST sent 


Retransmission of 
the ATTACH 
REQUEST or 
TRACKING AREA 
UPDATE 
REQUEST 


T3412 


NOTE 2 


EMM- 
REGISTERED 


In EMM-REGISTERED, when 
EMM-CONNECTED mode is 
left. 


When entering state 
EMM- 

DEREGISTERED or 
when entering 
EMM-CONNECTED 
mode. 


Initiation of the 
periodic TAU 
procedure 


T3416 


30s 


EMM- 
REGISTERED- 
INITIATED 
EMM- 
REGISTERED 
EMM- 
DEREGISTERED- 

INITIATED 
EMM-TRAGKING- 
AREA- 
UPDATING- 
INITIATED 
EMM-SERVICE- 
REQUEST- 
INITIATED 


RAND and RES stored as a 
result of a UMTS authentication 
challenge 


SECURITY MODE 

COMMAND 

received 

SERVICE REJECT 

received 

TRACKING AREA 
UPDATE ACCEPT 
received 

AUTHENTICATION 
REJECT received 
AUTHENTICATION 
FAILURE sent 
EMM- 

DEREGISTERED or 
EMM-NULL entered 


Delete the stored 
RAND and RES 


T3417 


5s 


EMM-SERVICE- 
REQUEST- 

1 K 1 iTi A "rr~ 

INITIATED 


SERVICE REQUEST sent 
EXTENDED SERVICE 
REQUEST sent in case f and g 

in subclause 5.6.1 .1 


Bearers have been 
set up 

SERVICE REJECT 
received 


Abort the procedure 


T3417ext 


10s 


EMM-SERVICE- 
REQUEST- 
INITIATED 


EXTENDED SERVICE 
REQUEST sent in case d in 
subclause 5.6.1 .1 
EXTENDED SERVICE 
REQUEST sent in case e in 
subclause 5.6.1 .1 and the CSFB 
response was set to "CS fallback 
accepted by the UE" 


Inter-system change 
from SI mode to 
A/Gb mode or lu 
mode is completed 

Inter-system change 
from S1 mode to 
A/Gb mode or lu 
mode is failed 
SERVICE REJECT 
received 


Abort the procedure 
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TIMER 
NUM. 


TIMER 
VALUE 


STATE 


CAUSE OF START 


NORMAL STOP 


ON 
EXPIRY 


T3418 


20s 


EMM- 
REGISTERED- 
INITIATED 
EMM- 
REGISTERED 
EMM-TRACKING- 
AREA- 
UPDATING- 
INITIATED 
EMM- 
DEREGISTERED- 

INITIATED 
EMM-SERVIGE- 
REQUEST- 
INITIATED 


AUTHENTICATION FAILURE 
(EMM cause = #20 "MAG failure" 
or #26 "Non-EPS authentication 
unacceptable") sent 


AUTHENTICATION 
REQUEST received 


On first expiry, the 
UE should consider 
the network as false 


T3420 


15s 


EMM- 
REGISTERED- 
INITIATED 
EMM- 
REGISTERED 
EMM- 
DEREGISTERED- 

INITIATED 
EMM-TRACKING- 
AREA- 
UPDATING- 
INITIATED 
EMM-SERVICE- 
REQUEST- 
INITIATED 


AUTHENTICATION FAILURE 
(cause = #21 "synch failure") 

sent 


AUTHENTICATION 
REQUEST received 


On first expiry, the 
UE should consider 
the network as false 


T3421 


15s 


EMM- 
DEREGISTERED- 
INITIATED 


DETACH REQUEST sent 


DETACH ACCEPT 
received 


Retransmission of 

DETACH 

REQUEST 


T3423 


NOTE 3 


EMM- 
REGISTERED 


T3412 expires while the UE is in 
EMM-REGISTERED.NO-CELL- 
AVAILABLE and ISR is 
activated. 


When entering state 
EMM- 

DEREGISTERED or 

when entering 

EMM-CONNECTED 

mode. 


Set TIN to "P-TMSI" 


T3430 


15s 


EMM-TRACKING- 
AREA- 
UPDATING- 
INITIATED 


TRACKING AREA UPDATE 
REQUEST sent 


TRACKING AREA 
UPDATE ACCEPT 
received 

TRACKING AREA 
UPDATE REJECT 
received 


Start T341 1 or 
T3402 as described 
in 

subclause 5.5.3.2.6 


T3440 


10s 


EMM- 
REGISTERED- 
INITIATED 
EMM-TRACKING- 
AREA- 
UPDATING- 
INITIATED 
EMM- 
DEREGISTERED- 

INITIATED 
EMM-SERVICE- 
REQUEST- 
INITIATED 
EMM- 
REGISTERED 


ATTACH REJECT, DETACH 
REQUEST, TRACKING AREA 
UPDATE REJECT with any of 
the EMM cause #11, #12, #13, 
#14 or #15 

SERVICE REJECT received 
with any of the EMM cause #1 1 , 
#12, #13 or #15 
TRACKING AREA UPDATE 
ACCEPT received after the UE 
sent TRACKING AREA 
UPDATE REQUEST in EMM- 
IDLE mode with no "active" flag 


Signalling 

connection released 
Bearers have been 
set up 


Release the 
signalling 
connection and 
proceed as 
described in 
subclause 5.3.1.2 


T3442 


NOTE 4 


EMM- 
REGISTERED 


SERVICE REJECT received 
with EMM cause #39 "CS 
domain temporarily not 
available" 


TRACKING AREA 
UPDATE 
REQUEST sent 


None 
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TIMER 
NUM. 


TIMER 
VALUE 


STATE 


CAUSE OF START 


NORMAL STOP 


ON 
EXPIRY 


NOTE 1 : The default value of this timer is used if the network does not indicate another value in an EMM signalling 
procedure. 

NOTE 2: The value of this timer is provided by the network operator during the attach and tracking area updating 
procedures. 

NOTE 3: The value of this timer may be provided by the network in the ATTACH ACCEPT message and TRACKING 
AREA UPDATE ACCEPT message. The default value of this timer Is identical to the value of T341 2. 

NOTE 4: The value of this timer is provided by the network operator when a service request for CS fallback is rejected 
by the network with EMM cause #39 "CS domain temporarily not available". 


Table 10.2.2: EPS mobility management timers - network side 


TIMER 
NUM. 


TIMER 
VALUE 


STATE 


CAUSE OF START 


NORMAL STOP 


ON THE 
1st, 2nd, 3rd, 4th 
EXPIRY (N0TE1) 


T3413 


NOTE 2 


EMM- 
REGISTERED 


Paging procedure for EPS 
services initiated 


Paging procedure 
for EPS services 
completed 


Network dependent 


T3422 


6s 


EMM- 
DEREGISTERED- 
INITIATED 


DETACH REQUEST sent 


DETACH ACCEPT 
received 


Retransmission of 
DETACH 

REQUEST 


T3450 


6s 


EMM-COMMON- 
PROC-INIT 


ATTACH ACCEPT sent 

TRACKING AREA UPDATE 
ACCEPT sent with GUTI 

GUTI REALLOCATION 
COMMAND sent 


ATTACH 

COMPLETE 

received 

TRACKING AREA 

UPDATE 

COMPLETE 

received 
GUTI 

REALLOCATION 

COMPLETE 

received 


Retransmission of 
the same message 
type, i.e. ATTACH 
ACCEPT, 
TRACKING AREA 
UPDATE ACCEPT 
or GUTI 

REALLOCATION 
COMMAND 


T3460 


6s 


EMM-COMMON- 
PROC-INIT 


AUTHENTICATION REQUEST 

sent 

SECURITY MODE COMMAND 
sent 


AUTHENTICATION 

RESPONSE 

received 

AUTHENTICATION 
FAILURE received 
SECURITY MODE 
COMPLETE 

received 

SECURITY MODE 
REJECT received 


Retransmission of 
the same message 
type, i.e. 

AUTHENTICATION 
REQUEST 
or SECURITY 
MODE COMMAND 


T3470 


6s 


EMM-COMMON- 
PROC-INIT 


IDENTITY REQUEST sent 


IDENTITY 
RESPONSE 

received 


Retransmission of 

IDENTITY 

REQUEST 


Mobile 
reachable 


Default 4 
min greater 
than T3412 


All except EMM- 
DEREGISTERED 


Entering EMM-IDLE mode 


NAS signalling 

connection 

established 


Network dependent, 
but typically paging 
is halted on 1st 
expiry 


Implicit 
detach 
timer 


NOTE 3 


All except EMM- 
DEREGISTERED 


The mobile reachable timer 
expires while the network is in 
EMM-IDLE mode 


NAS signalling 
connection 

established 


Implicitly detach the 
UE on 1st expiry 



NOTE 1 : Typically, the procedures are aborted on the fifth expiry of the relevant timer. Exceptions are described in the 

corresponding procedure description. 
NOTE 2: The value of this timer is network dependent. 

NOTE 3: The value of this timer is network dependent. If ISR is activated, the default value of this timer is 4 minutes 
greater than T3423. 
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10.3 Timers of EPS session management 



Table 10.3.1 : EPS session management timers - UE side 



TIMER 
NUM. 


TIMER 
VALUE 


STATE 


CAUSE OF START 


NORMAL STOP 


ON THE 
1st, 2nd, 3rd, 4th 
EXPIRY (NOTE 1) 


T3480 


8s 


PROCEDURE 
TRANSACTION 
PENDING 


BEARER RESOURCE 
ALLOCATION REQUEST sent 


ACTIVATE 
DEDICATED EPS 
BEARER 
CONTEXT 
REQUEST received 
or MODIFY EPS 
BEARER 
CONTEXT 
REOUEST received 
or BEARER 
RESOURCE 
ALLOCATION 
REJECT received 


Retransmission of 

BEARER 

RESOURCE 

ALLOCATION 

REQUEST 


T3481 


8s 


PROCEDURE 
TRANSACTION 
PENDING 


BEARER RESOURCE 
MODIFICATION REQUEST sent 


ACTIVATE 
DEDICATED EPS 
BEARER 
CONTEXT 
REQUEST received 
or MODIFY EPS 
BEARER 
CONTEXT 
REOUEST received 
or DEACTIVATE 
EPS BEARER 
CONTEXT 
REOUEST received 
or BEARER 
RESOURCE 
MODIFICATION 
REJECT received 


Retransmission of 

BEARER 

RESOURCE 

MODIFICATION 

REQUEST 


T3482 


8s 


PROCEDURE 
TRANSACTION 
PENDING 


An additional PDN connection is 
requested by the UE which is not 
combined in attach procedure 


ACTIVE DEFAULT 
EPS BEARER 
CONTEXT 
REOUEST received 
or PDN 

CONNECTIVITY 
REJECT received 


Retransmission of 
PDN 

CONNECTIVITY 
REQUEST 


T3492 


6s 


PROCEDURE 
TRANSACTION 
PENDING 


PDN DISCONNECT REQUEST 

sent 


DEACTIVATE EPS 
BEARER 
CONTEXT 
REOUEST received 
or PDN 

DISCONNECT 
REJECT received 


Retransmission of 
PDN DISCONNECT 
REQUEST 


NOTE 1 : Typically, tlie procedures are aborted on the fifth expiry of the relevant timer. Exceptions are described in the 
corresponding procedure description. 
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Table 10.3.2: EPS session management timers - networic side 



TIMER 
NUM. 


TIMER 
VALUE 


STATE 


CAUSE OF START 


NORMAL STOP 


ON THE 
1st, 2nd, 3rd, 4th 
EXPIRY (NOTE 1) 


T3485 


8s 


BEARER 
CONTEXT 

ACTIVE 
PENDING 


ACTIVATE DEFAULT EPS 
BEARER CONTEXT REQUEST 
sent 

ACTIVATE DEDICATED EPS 
BEARER CONTEXT REQUEST 
sent 


ACTIVATE 
DEFAULT EPS 
BEARER 

CONTEXT ACCEPT 

received 

or ACTIVATE 

DEFAULT EPS 

BEARER 

CONTEXT REJECT 

received 

or ACTIVATE 

DEDICATED EPS 

BEARER 

CONTEXT ACCEPT 

received 

or ACTIVATE 

DEDICATED EPS 

BEARER 

CONTEXT REJECT 
received 


Retransmission of 
the same message 


T3486 


8s 


BEARER 
CONTEXT 

MODIFY 
PENDING 


MODIFY EPS BEARER 
CONTEXT REQUEST sent 


MODIFY EPS 
BEARER 

CONTEXT ACCEPT 

received 

or MODIFY EPS 

BEARER 

CONTEXT REJECT 
received 


Retransmission of 
MODIFY EPS 
BEARER 
CONTEXT 
REQUEST 


T3489 


4s 


PROCEDURE 
TRANSACTION 
PENDING 


ESM INFORMATION REQUEST 
sent 


ESM 

INFORMATION 

RESPONSE 

received 


Retransmission of 
ESM 

INFORMATION 
REQUEST on 1st 
and 2nd expiry only 


T3495 


8s 


BEARER 
CONTEXT 
INACTIVE 
PENDING 


DEACTIVATE EPS BEARER 
CONTEXT REQUEST sent 


DEACTIVATE EPS 
BEARER 

CONTEXT ACCEPT 
received 


Retransmission of 
DEACTIVATE EPS 
BEARER 
CONTEXT 
REQUEST 


NOTE 1 : Typically, the procedures are aborted on the fifth expiry of the relevant timer. Exceptions are described in the 
corresponding procedure description. 
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Annex A (informative): 

Cause values for EPS mobility management 

A.1 Causes related to UE identification 

Cause #2 - IMSI unknown in HSS 

This EMM cause is sent to the UE if the UE is not known (registered) in the HSS. This EMM cause does not 
affect operation of the EPS service, although is may be used by an EMM procedure. 

Cause #3 - Illegal UE 

This EMM cause is sent to the UE when the network refuses service to the UE either because an identity of the 
UE is not acceptable to the network or because the UE does not pass the authentication check, i.e. the RES 
received from the UE is different from that generated by the network. 

Cause #6 -Illegal ME 

This EMM cause is sent to the UE if the ME used is not acceptable to the network, e.g. blacklisted. 

Cause #9 - UE identity cannot be derived by the network. 

This EMM cause is sent to the UE when the network cannot derive the UE's identity from the GUTI/S-TMSI/P- 
TMSI and RAI e.g. no matching identity/context in the network or failure to validate the UE's identity due to 
integrity check failure of the received message. 

Cause #10 - Implicitly detached 

This EMM cause is sent to the UE either if the network has implicitly detached the UE, e.g. some while after the 
Mobile reachable timer has expired, or if the EMM context data related to the subscription does not exist in the 
MME e.g. because of a MME restart. 

A.2 Cause related to subscription options 

Cause #7 - EPS services not allowed 

This EMM cause is sent to the UE when it is not allowed to operate EPS services. 
Cause #8 - EPS services and non-EPS services not allowed 

This EMM cause is sent to the UE when it is not allowed to operate either EPS or non-EPS services. 

Cause #11 - PLMN not allowed 

This EMM cause is sent to the UE if it requests tracking area updating in a PLMN where the UE, by subscription 
or due to operator determined barring, is not allowed to operate. 

Cause #12 - Tracking area not allowed 

This EMM cause is sent to the UE if it requests tracking area updating in a tracking area where the HPLMN 
determines that the UE, by subscription, is not allowed to operate. 

NOTE 1: If EMM cause #12 is sent to a roaming subscriber the subscriber is denied service even if other PLMNs 
are available on which registration was possible. 

Cause #13 - Roaming not allowed in this tracking area 

This EMM cause is sent to an UE which requests tracking area updating in a tracking area of a PLMN which by 
subscription offers roaming to that UE but not in that tracking area. 
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Cause #14 - EPS services not allowed in this PLMN 

This EMM cause is sent to the UE which requests EPS service in a PLMN which does not offer roaming for EPS 
services to that UE. 

NOTE 2: Since only one Ust of forbidden PLMNs for packet services is maintained in the UE, then the "forbidden 
PLMNs for GPRS service" is the maintained Ust and the forbidden PLMNs for EPS service is equivalent 
to it. 

Cause #15 - No suitable cells in tracking area 

This EMM cause is sent to the UE if it requests tracking area updating in a tracking area where the UE, by 
subscription, is not allowed to operate, but when it should find another allowed tracking area in the same PLMN. 

NOTE 3: Cause #15 and cause #12 differ in the fact that cause #12 does not trigger the UE to search for another 
allowed tracking area on the same PLMN. 

Cause #25 - Not authorized for this CSG 

This EMM cause is sent to the UE if it requests access in a CSG cell with CSG ID where the UE, by 
subscription, is not allowed to operate, but when it should find another cell in the same PLMN. 

Cause #40 - No EPS bearer context activated 

This EMM cause is sent to the UE, if during a tracking area updating procedure the MME detects that there is no 
active EPS bearer context in the network. 



A.3 Causes related to PLMN specific network failures 
and congestion/authentication failures 

Cause #16 - MSC temporarily not reachable 

This EMM cause is sent to the UE if it requests a combined EPS attach or tracking area updating in a PLMN 
where the MSC is temporarily not reachable via the EPS part of the network. 

Cause #17 - Network failure 

This EMM cause is sent to the UE if the MME cannot service an UE generated request because of PLMN 
failures. 

Cause #18 - CS domain not available 

This EMM cause is sent to the UE if the MME cannot service an UE generated request because of no availabiUty 
of CS domain. 

Cause #19 - ESM failure 

This EMM cause is sent to the UE when there is a failure in the ESM message contained in the EMM message. 

Cause #20 - MAC failure 

This EMM cause is sent to the network if the USIM detects that the MAC in the AUTHENTICATION 
REQUEST message is not fresh (see 3GPP TS 33.401 [19]). 

Cause #21 - Synch failure 

This EMM cause is sent to the network if the USIM detects that the SQN in the AUTHENTICATION 
REQUEST message is out of range (see 3GPP TS 33.401 [19]). 

Cause #22 - Congestion 

This EMM cause is sent to the UE because of congestion in the network (e.g. no channel, facility busy/congested 
etc.). 
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Cause #23 - UE security capabilities mismatch 

This EMM cause is sent to the network if the UE detects that the UE security capabiUty does not match the one 
sent back by the network. 

Cause #24 - Security mode rejected, unspecified 

This EMM cause is sent to the network if the security mode command is rejected by the UE if the UE detects 
that the nonccuE does not match the one sent back by the network or for unspecified reasons. 

Cause #26 - Non-EPS authentication unacceptable 

This EMM cause is sent to the network in SI mode if the "separation bit" in the AMP field of AUTN is set to 
in the AUTHENTICATION REQUEST message (see 3GPP TS 33.401 [19]). 

Cause #39 - CS domain temporarily not available 

This EMM cause is sent to the UE when the CS fallback or IxCS fallback request cannot be served temporarily 
due to O&M reasons. 



A.4 Causes related to nature of request 

NOTE: This subclause has no entries in this version of the specification 

A.5 Causes related to invalid messages 

Cause value #95 - Semantically incorrect message. 

See 3GPP TS 24.008 [13], annex H, subclause H.5.5. 
Cause value #96 - Invalid mandatory information. 

See 3GPP TS 24.008 [13], annex H, subclause H.6.1. 
Cause value #97 - Message type non-existent or not implemented. 

See 3GPP TS 24.008 |13|, annex H, subclause H.6.2. 
Cause value #98 - Message type not compatible with protocol state. 

See 3GPP TS 24.008 [13], annex H, subclause H.6.3. 
Cause value #99 - Information element non-existent or not implemented. 

See 3GPP TS 24.008 [13], annex H, subclause H.6.4. 
Cause value #100 - Conditional IE error. 

See 3GPP TS 24.008 [13], annex H, subclause H.6.5. 
Cause value #101 - Message not compatible with protocol state. 

See 3GPP TS 24.008 [13], annex H, subclause H.6.6. 
Cause value #1 1 1 - Protocol error, unspecified. 

See 3GPP TS 24.008 [13], annex H, subclause H.6.8. 
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Annex B (informative): 

Cause values for EPS session management 

B.1 Causes related to nature of request 

Cause #8 - Operator Determined Barring 

This ESM cause is used by the network to indicate that the requested service was rejected by the MME due to 
Operator Determined Barring. 

Cause #26 - Insufficient resources 

This ESM cause is used by the UE or by the network to indicate that the requested service cannot be accepted 
due to insufficient resources. 

Cause #27 - Unknown or missing access point name 

This ESM cause is used by the network to indicate that the requested service was rejected by the external packet 
data network because the access point name was not included although required or if the access point name 
could not be resolved. 

Cause #28 - Unknown PDN type 

This ESM cause is used by the network to indicate that the requested service was rejected by the external packet 
data network because the PDN type could not be recognised. 

Cause #29 - User authentication failed 

This ESM cause is used by the network to indicate that the requested service was rejected by the external packet 
data network due to a failed user authentication. 

Cause #30 - Activation rejected by Serving GW or PDN GW 

This ESM cause is used by the network to indicate that the requested service was rejected by the Serving GW or 
PDN GW. 

Cause #31 - Activation rejected, unspecified 

This ESM cause is used by the network to indicate that the requested service was rejected due to unspecified 
reasons. 

Cause #32 - Service option not supported 

This ESM cause is used by the network when the UE requests a service which is not supported by the PLMN. 
Cause #33 - Requested service option not subscribed 

This ESM cause is sent when the UE requests a service option for which it has no subscription. 

Cause #34 - Service option temporarily out of order 

This ESM cause is sent when the network cannot service the request because of temporary outage of one or more 
functions required for supporting the service. 

Cause #35 - PTI already in use 

This ESM cause is used by the network to indicate that the PTI included by the UE is already in use by another 
active UE requested procedure for this UE. 

Cause #36 - Regular deactivation 

This ESM cause is used to indicate a regular UE or network initiated release of EPS bearer resources. 
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Cause #37 - EPS QoS not accepted 

This ESM cause is used by the network if the new EPS QoS cannot be accepted that was indicated in the UE 

request. 

Cause #38 - Network failure 

This ESM cause is used by the network to indicate that the requested service was rejected due to an error 

situation in the network. 

Cause #41 - Semantic error in the TFT operation. 

This ESM cause is used by the network or the UE to indicate that the requested service was rejected due to a 
semantic error in the TFT operation included in the request. 

Cause #42 - Syntactical error in the TFT operation. 

This ESM cause is used by the network or the UE to indicate that the requested service was rejected due to a 
syntactical error in the TFT operation included in the request. 

Cause #43 - Invalid EPS bearer identity 

This ESM cause is used by the network or the UE to indicate that the EPS bearer identity value provided to it is 
not a valid value for the received message or the EPS bearer context identified by the linked EPS bearer identity 
IE in the request is not active. 

Cause #44 - Semantic errors in packet filter(s) 

This ESM cause is used by the network or the UE to indicate that the requested service was rejected due to one 
or more semantic errors in packet filter(s) of the TFT included in the request. 

Cause #45 - Syntactical error in packet filter(s) 

This ESM cause is used by the network or the UE to indicate that the requested service was rejected due to one 
or more syntactical errors in packet filter(s) of the TFT included in the request. 

Cause #46 - EPS bearer context without TFT already activated 

This ESM cause is used by the network or the UE to indicate that it has already activated an EPS bearer context 
without TFT. 

Cause #47 - PTI mismatch 

This ESM cause is used by the UE to indicate that the PTI value which is included in the ESM message that the 
UE receives does not match a PTI in use. 

Cause #49 - Last PDN disconnection not allowed 

This ESM cause is used by the network to indicate that the UE requested PDN disconnection procedure on the 
last remaining PDN connection is not allowed. 

Cause #50 - PDN type IPv4 only allowed 

This ESM cause is used by the network to indicate that only PDN type IPv4 is allowed for the requested PDN 

connectivity. 

Cause #5 1 - PDN type IPv6 only allowed 

This ESM cause is used by the network to indicate that only PDN type IPv6 is allowed for the requested PDN 
connectivity. 

Cause #52 - single address bearers only allowed 

This ESM cause is used by the network to indicate that the requested PDN connectivity is accepted with the 
restriction that only single IP version bearers are allowed. 

Cause #53 - ESM information not received 



ETSI 



3GPP TS 24.301 version 8.2.1 Release 8 



231 



ETSI TS 124 301 V8.2.1 (2009-06) 



This ESM cause is used by the network to indicate that the PDN connectivity procedure was rejected due to the 

ESM information was not received. 

Cause #54 - PDN connection does not exist 

This ESM cause is used by the network at handover from a non-3GPP access network to indicate that the MME 
does not have any information about the requested PDN connection. 

Cause #55 - Muhiple PDN connections for a given APN not allowed 

This ESM cause is used by the network to indicate that the PDN connectivity procedure was rejected due to 
multiple PDN connections for a given APN are not allowed. 

Cause #56 - Collision with network initiated request 

This ESM cause is used by the network to indicate that the network has already initiated the activation, 
modification or deactivation of bearer resources which was requested by the UE. 

Cause #81 - InvaUd PTI value 

This ESM cause is used by the network or UE to indicate that the PTI provided to it is unassigned or reserved. 

Cause #112 - APN restriction value incompatible with active EPS bearer context. 

This ESM cause is used by the network to indicate that the EPS bearer context(s) have an APN restriction value 
that is not allowed in combination with a currently active EPS bearer context. Restriction values are defined in 
3GPPTS 23.060 [4]. 



B.2 Protocol errors (e.g., unknown message) class 

Cause #95 - Semantically incorrect message 

This ESM cause is used to report receipt of a message with semantically incorrect contents. 

Cause #96 - InvaUd mandatory information 

This ESM cause indicates that the equipment sending this ESM cause has received a message with a non- 
semantical mandatory IE error. 

Cause #97 - Message type non-existent or not implemented 

This ESM cause indicates that the equipment sending this ESM cause has received a message with a message 
type it does not recognize either because this is a message not defined, or defined but not implemented by the 
equipment sending this ESM cause. 

Cause #98 - Message type not compatible with protocol state 

This ESM cause indicates that the equipment sending this ESM cause has received a message not compatible 
with the protocol state. 

Cause #99 - Information element non-existent or not implemented 

This ESM cause indicates that the equipment sending this ESM cause has received a message which includes 
information elements not recognized because the information element identifier is not defined or it is defined but 
not implemented by the equipment sending the ESM cause. However, the information element is not required to 
be present in the message in order for the equipment sending the ESM cause to process the message. 

Cause #100 - Conditional IE error 

This ESM cause indicates that the equipment sending this cause has received a message with conditional IE 
errors. 

Cause #101 - Message not compatible with protocol state 

This ESM cause indicates that a message has been received which is incompatible with the protocol state. 
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Cause #1 1 1 - Protocol error, unspecified 

This ESM cause is used to report a protocol error event only when no other ESM cause in the protocol error class 
applies. 
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Annex C (normative): 
Storage of EMM information 

The following EMM parameters shall be stored on the USIM if the corresponding file is present: 

- GUTI; 

- last visited registered TAI; 

- EPS update status; 

- Allowed CSG Ust; and 

- EPS security context parameters. 

The presence and format of corresponding files on the USIM is specified in 3GPP TS 31.102 [17]. 

If the corresponding file is not present on the USIM, these EMM parameters except allowed CSG list are stored in a 
non-volatile memory in the ME together with the IMSI from the USIM. The allowed CSG Ust is stored in a non-volatile 
memory in the ME if the UE supports CSG selection. These EMM parameters can only be used if the IMSI from the 
USIM matches the IMSI stored in the non-volatile memory; else the UE shall delete the EMM parameters. 

The following EMM parameter shall be stored in a non- volatile memory in the ME together with the IMSI from the 
USIM: 

- TIN. 

This EMM parameter can only be used if the IMSI from the USIM matches the IMSI stored in the non-volatile 
memory; else the UE shall delete the EMM parameter. 
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Annex D (normative): 
Establishment cause (S1 mode only) 

D.1 Mapping of NAS procedure to RRC establishment 
cause (S1 mode only) 

When EMM requests the estabhshment of a NAS-signalling connection, the RRC establishment cause used by the UE 
shall be selected according to the NAS procedure as specified in table D.1.1. The EMM shall also indicate to the lower 
layer for the purpose of access control, the call type associated with the RRC establishment cause as specified in 
table D.1.1. 



Table D.1.1 : Mapping of NAS procedure to establishment cause and call type 



NAS procedure 


RRC establishment cause (according 3GPP TS 36.331 [22]) 


Call type 


Attach 


MO signalling (See Note 1) 


"originating signalling" 


Tracking Area Update 


Mu Signalling (oee iNote \ j 


"originating signalling" 


Detach 


MO signalling (See Note 1) 


"originating signalling" 


Service Request 


If a SERVICE REQUEST is to request user plane radio 
resources, the RRC establishment cause shall be set to MO 
data. (See Note1) 


"originating calls" 




If a SERVICE REQUEST is to request resources for UL 
signalling, the RRC establishment cause shall be set to MO 
data. (See Note 1) 


"originating calls" 




If a SERVICE REQUEST is a response to paging where the CN 
domain indicator is set to "PS", the RRC establishment cause 
shall be set to MT access. (See Note 1 ) 


"terminating calls" 




If a EXTENDED SERVICE REQUEST has service type set to 
"mobile originating CS fallback", the RRC establishment cause 
shall be set to MO data. (See Note1). 


"originating calls" 




If a EXTENDED SERVICE REQUEST has service type set to 
"mobile terminating CS fallback", the RRC establishment cause 
shall be set to MT access. (See Note1). 


"terminating calls" 




If a EXTENDED SERVICE REQUEST has service type set to 
"mobile originating CS fallback emergency call", the RRC 
establishment cause shall be set to Emergency call. 
(See Note1). 


"emergency calls" 


Note 1 : For these NAS procedures initiated by UEs of access class 12, 1 3 or 1 4 in their home country, the RRC 

establishment cause will be set to "High priority access AC 11 - 1 5". For this purpose the home country is 
defined as the country of the MCC part of the IMSI, see 3GPP TS 22.01 1 [1 A]. 

For these NAS procedures initiated by UE of access class 11 or 15 in their HPLMN (if the EHPLMN list is 
not present or is empty) or EHPLMN (if the EHPLIVIN list is present), the RRC establishment cause will be 
set to "High priority access AC 1 1 - 1 5". 



NOTE: The RRC establishment cause can be used by the network to prioritise the connection establishment 
request from the UE at high load situations in the network. 
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Request 
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Clarification of UE requested ESM procedures 


8.0.0 


8.1.0 


2009-03 


CT-43 


CP-090157 


0208 
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request, EPS bearer context modification request and bearer 
resource aliocation request procedures 
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